<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc docName="draft-bryant-mpls-aux-data-pointer-00" category="std">

  <front>
    <title abbrev="MPLS-Aux-Ptr">Use of an MPLS LSE as an Ancillary Data Pointer</title>

    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="A." surname="Clemm" fullname="Alexander Clemm">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <email>ludwig@clemm.org</email>
      </address>
    </author>
    <author initials="T." surname="Eckert" fullname="Toerless Eckert">
      <organization>Futurewei Technologies, Inc.</organization>
      <address>
        <email>tte@cs.fau.de</email>
      </address>
    </author>

    <date year="2021" month="May" day="18"/>

    
    <workgroup>MPLS</workgroup>
    

    <abstract>


<t>The purpose of this memo is to describe how Label Stack Entries (LSEs) can
be used to point to ancillary or meta-data carried below the MPLS label stack.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>There has been significant recent interest in developing the  MPLS data plane to
address new needs, and in particular to carry ancillary or meta-data below
the stack. In this document we consider that this ancillary data
is further subdivided into a sequence of blocks. This
draft does not prescribe the information or its structure of the ancillary data.
For the sake of examples, it could range from
a single ancillary data unit to a structured set of ancillary data blocks similar to an IPv6 extension
header. There has also been recent interest in carrying additional flags
or other indicators to qualify the forwarding operations.</t>

<t>This memo proposes the use of “spare” bits in a Special Purpose Label (SPL) <xref target="I-D.kompella-mpls-mspl4fa"/>
be used as a pointer to items of ancillary data carried  below the
bottom of stack (BoS). Finally we speculate that in certain network scopes
we may usefully be able to create pseudo-SPLs from the ordinary label pool.</t>

</section>
<section anchor="background-documents" title="Background Documents">

<t><xref target="I-D.kompella-mpls-mspl4fa"/> notes that the forwarder does not need
to use the TC, or TTL fields in an LSE <xref target="RFC3032"/> that does not become top of
stack (ToS). It proposes to exploit these fields as indicators
of forwarding actions, by modifying the semantics of these fields.</t>

<t>There are a number of key proposals in that draft:</t>

<t><list style="symbols">
  <t>Using the “spare bits” as forwarding indicator flags to
specify actions or in some cases inactions</t>
  <t>Using the method to multi-purpose SPLs and thus expand the
number of single label SPLs available to the IETF.</t>
  <t>Reuse the Entropy Label (EL) fields to carry additional
data needed by the forwarder. This latter point could be adopted by
any eSPL. One use for this additional data that was proposed
(certainly in discussion but I cannot see it in the draft) was the
use of this facility to carry a network slice identifier.</t>
</list></t>

<t>This draft proposes that these “spare” bits in an SPL or pseudo-SPL be
used as a pointer to ancillary data below the stack.</t>

<t>This proposal can be used in conjunction with the other indicator
proposals, for example by using different SPLs for different options,
such as one SPL indicating the presence of a pointer vs one or more
other SPLs for the other proposals.</t>

</section>
<section anchor="use-of-spls-as-pointers" title="Use of SPLs as Pointers">

<t>Previously it had been proposed to use the “spare” bits in an SPL that is not ToS as a bit
field or as an enumerator of a slice.
However, it would appear to be an advantage to take things a bit further and use them as a pointer to
ancillary data below the BoS.  This ancillary data can then be accessed and processed as needed whenever the SPL is 
being processed.</t>

<t>The advantages of doing this are:</t>

<t><list style="symbols">
  <t>The ability to find the ancillary data without scanning the whole stack.
Speculatively scanning the label stack can be expensive in Network Processor Unit (NPU) processing time,
particularly if the stack is deep.</t>
  <t>Ability to specify which ancillary data is applicable at the hop being processed.</t>
  <t>The use of a pointer or set of pointers allows for a simple packet parser.</t>
  <t>The approach is inherently  general and  extensible.</t>
</list></t>

<t>This concept is illustrated in <xref target="FIG-mpls-ptr"/>.</t>

<figure title="Use of In-stack MPLS pointer" anchor="FIG-mpls-ptr"><artwork><![CDATA[
     +-------------------------+
  L1 |      Top of Stack       | 
     +-------------------------+
  L2 |      Pointer SPL        |-----+
     +-------------------------+     |
     |                         |     |
     .                         .     |
     .                         .     |
     |                         |     |
     +-------------------------+     |
     |      Bottom of Stack    |     |
   ===============================   |
     |      Ancillary Data     |     |
     .                         .     |
     .                         .<----+
     |                         |     
     +-------------------------+
]]></artwork></figure>

<t>The ToS label (L1) and Pointer SPL (L2) form a tuple
with the semantic “process the action that the Forwarding Equivalence Class (FEC) of the ToS label specifies with the 
assistance of the information pointed to by the following SPL”. Ideally L2 is SPL requiring a single LSE rather than an Extended SPL (ESPL) requiring
two LSEs. Whilst the additional LSE required for an ESPL may not initially seem significant, the authors imagine that there may be cases
where multiple pointer labels will be required.</t>

<t>Let us consider the case when the ToS is not an SPL of any kind.
In this case, the forwarder looks at the following LSE (i.e., the LSE that immediately succeeds the ToS). 
If that LSE is not a pointer SPL, forwarding is performed as
normal. If, on the other hand, the following label is a pointer SPL, the forwarder uses the information pointed to
by the pointer  as assistance in the forwarding operation.</t>

<t>Note that whilst the pointer can be simply point to the end of the stack, which
aligns with the other  MPLS proposals being made, the ideas discussed here can actually point to a specific
item within the MPLS  payload i.e. to a specific item of ancillary data.
This in turn also means that different LSEs can point to different ancillary data components. 
This allows the MPLS application or packet designer to express sophisticated behavior in
which it is possibly to apply different ancillary data to different LSEs, i.e. 
different network segments.</t>

</section>
<section anchor="label-operations-popping-and-swapping" title="Label Operations: Popping and Swapping">

<t>When the ToS is popped, consideration needs to be given to any Pointer SPL immediately following it.<vspace />
In the basic case, a Pointer SPL will simply be popped along with the ToS.</t>

<t>There will be cases in in which the same Pointer SPL applies to multiple labels.  In those cases, 
requiring the forwarder to pop the Pointer SPL along with the ToS results in the need to carry multiple instances of the same 
Pointer SPL, one for each label to which it applies.  As an optimization, it will make sense to offer a 
second behavioral option in which, upon popping the ToS, any subsequent Pointer SPL will be swapped with the next FEC label. 
This case is depicted in <xref target="FIG-popswapbefore"/> and <xref target="FIG-popswapafter"/>.</t>

<figure title="Before Pop - Swap operation: " anchor="FIG-popswapbefore"><artwork><![CDATA[
     +-------------------------+
  L1 |      Top of Stack       |
     +-------------------------+
  L2 |      Pointer SPL        |-----+
     +-------------------------+     |
  L3 |         Next LSE        |     |
     +-------------------------+     |
  L4 |         Whatever        |     |
     +-------------------------+     |
     .                         .     |
     |                         |     |
     +-------------------------+     |
     |      Bottom of Stack    |     |
   ===============================   |
     |      Ancillary Data     |     |
     .                         .     |
     .                         .<----+
     |                         |     
     +-------------------------+
]]></artwork></figure>

<figure title="After Pop - Swap operation: " anchor="FIG-popswapafter"><artwork><![CDATA[
     +-------------------------+
  L3 |  Next LSE (New ToS)     |
     +-------------------------+
  L2 |        Pointer SPL      |-----+
     +-------------------------+     |
  L4 |         Whatever        |     |
     +-------------------------+     |
     .                         .     |
     .                         .     |
     |                         |     |
     +-------------------------+     |
     |      Bottom of Stack    |     |
   ===============================   |
     |      Ancillary Data     |     |
     .                         .     |
     .                         .<----+
     |                         |     
     +-------------------------+
]]></artwork></figure>

<t>When this optimization is applied, there needs to be a distinction that allows a forwarder to determine 
whether a Pointer SPL should be popped along with its ToS, or whether it should be swapped 
with the next FEC label below.  <vspace />
One possibility is to indicate this in the FEC of the LSE that precedes the Pointer SPL, or perhaps it can be indicated
by using one of its bits as a corresponding flag. Alternatively a perhaps some method
can be found whereby a “TTL” can be associated with the pointer label.
How to best indicate this end-of-use distinction is for further study.</t>

</section>
<section anchor="use-of-multiple-pointers" title="Use of Multiple Pointers">

<t>One problem to be solved is how to support
multiple independent (sets of) ancillary data in the
MPLS header in support of different (forwarding, OAM etc)
operations associated with the ancillary data. In IP/IPv6, ancillary data is encoded in the packet header
through a sequence of Extension Headers (EH). For IPv6,
<xref target="RFC8200"/> defines several EH types, each of which implies
a specific set of nodes that have to process the EH
and their order.  This
approach results in a complex parsing requirement for
IPv6 packets when multiple extension headers are used
and very rigid encoding and EH semantic difficult to extend.</t>

<t>Instead of limiting processing to a single pointer, it is possible to generalize the above concepts 
to allow for multiple pointers. This increases flexibility by allowing the packet designer to include pointers to multiple 
sets of ancillary data, each of which can be potentially used for a different purpose.<vspace />
Therefore, the use of multiple adjacent Pointer SPLs is allowed. This means that ToS processing takes into considerations
all Pointer SPLs that immediately follow.</t>

<t>A pointer mechanism in the MPLS label stack provides a
method of using multiple pointers to express two (or more) sets of ancillary data,
for example a latency object and an iOAM object. An example is shown in <xref target="FIG-mpls-multi-ptr"/>.</t>

<figure title="Use of Multiple In-stack MPLS Pointers" anchor="FIG-mpls-multi-ptr"><artwork><![CDATA[
     +-------------------------+
  L1 |      Top of Stack       |
     +-------------------------+
  L2 |      Pointer SPL        |-----+
     +-------------------------+     |
  L3 |      Pointer SPL        |-----|---+
     +-------------------------+     |   |
     |                         |     |   |
     .                         .     |   |
     .                         .     |   |
     |                         |     |   |
     +-------------------------+     |   |
     |      Bottom of Stack    |     |   |
   ===============================   |   |
     |      Ancillary Data     |     |   |
     .                         .     |   |
     .                         .<----+   |
     .                         .         |
     .                         .<--------+
     |                         |     
     +-------------------------+
]]></artwork></figure>

<t>As in <xref target="FIG-mpls-ptr"/> the top three labels are a tuple that in this
case have the semantics “process the action that the FEC of the ToS 
label specifies with the assistance of the information pointed to by the following SPLs”,
in this case the label set L1, L2, L3. The tuple terminates when either an
“ordinary” label, an SPL that is not a pointer SPL, or a label with the S bit set
is encountered.</t>

<t>The <xref target="FIG-mpls-multi-ptr2"/> further illustrates this capability.
Here in this example two
LSEs, Li and Lj, are each associated with two pointers.
The FEC of Li therefore indicates that execution of
Li includes the use of Ancillary Data 1 and 2, and
execution of Lj includes the use of ancillary data
2 and 3.</t>

<figure title="Further Example of Multiple In-stack MPLS Pointers" anchor="FIG-mpls-multi-ptr2"><artwork><![CDATA[
      +-------------------------+
 L1   |      Top of Stack       |
      +-------------------------+
      .                         .
      +-------------------------+      
 Li   | FEC     LSE             |      
      | Pointer                 |---------+
      | Pointer                 |-----+   |
      +-------------------------+     |   |
      |                         |     |   |
      .                         .     |   |
      +-------------------------+     |   |
 Lj   | FEC     LSE             |     |   |
      | Pointer                 |-----|---+
      | Pointer                 |---+ |   |
      +-------------------------+   | |   |
      .                         .   | |   |
      |                         |   | |   |
      +-------------------------+   | |   |
      |      Bottom of Stack    |   | |   |
      ===========================   | |   |
      |   Ancillary Data 1      |<--|-+   |
      .                         .   |     |
      +-------------------------+   |     |
      |  Ancillary Data 2       |<--|-----+
      .                         .   |  
      +-------------------------+   |
      |  Ancillary Data 3       |<--+ 
      .                         .
      ...........................
      .         ...             .
      +-------------------------+
]]></artwork></figure>

<t>To support multiple Pointer SPLs, the following additional considerations apply:</t>

<t>The pop operation for the ToS needs to be extended to apply to the entire tuple of Pointer SPLs that are in its scope, 
i.e. that immediately succeed it. The default pop behavior will be to pop the entire tuple of Pointer SPLs along with the ToS.</t>

<t>As described earlier, as an optimization to reduce the size of the label stack, Pointer SPLs can 
be designated to not be popped but instead swapped with other LSEs in the stack.
This will allow the same Pointer SPL set to be applied to multiple LSEs.<vspace />
For an in stack  swap operation where multiple pointers form a pointer set, the entire tuple, or group, would be
swapped with the next FEC label below.</t>

<t>In addition, mixed cases are conceivable in which some Pointer SPLs are popped whereas others are swapped. Whether
to pop or swap a Pointer SPL needs to be 
specified as part of the associated LSE’s disposition behavior.</t>

</section>
<section anchor="disposition-of-the-ancillary-data" title="Disposition of the Ancillary Data">

<t>The ancillary data must be removed before the payload is passed out of the MPLS
domain. There are three methods whereby the egress PE can know of the presence of the
ancillary data:</t>

<t><list style="symbols">
  <t>The FEC of the BoS LSE can indicate the need to do this in a manner similar to pseudowires or MPLS VPN.</t>
  <t>The BoS LSE can be a special purpose label indicating the presence of the ancillary data.</t>
  <t>The BOS LSE can point to an item of ancillary data that describes the disposition of the ancillary data.</t>
</list></t>

<t>The removal of the ancillary data may be relatively complex depending on its purpose, i.e. it
may be more complex than removing some number of bytes, for example,  if it is
carrying latency or iOAM information.</t>

<t>The structure and quantity of ancillary data including any methods whereby the ancillary
data points to other ancillary, or whether there are pointer to the payload
itself is out of scope for this document. Such information will need to be
included in the ancillary data design so that it can be safely processed and/or removed.</t>

</section>
<section anchor="structure-of-ancillary-data" title="Structure of Ancillary Data">

<t>The structure of the ancillary data is outside the scope of this memo.</t>

</section>
<section anchor="structure-of-pointer-label" title="Structure of Pointer Label">

<t>A possible structure for a pointer LSE is shown in <xref target="FIG-mpls--ptr-LSE"/>.</t>

<figure title="MPLS Pointer LSE" anchor="FIG-mpls--ptr-LSE"><artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Label                  | Flg |S|   Pointer     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Label      : contains the label that triggers the pointer behavior

Flg (Flags): Contains a number of flags that clarify the pointer
     Bit 20: Size of pointer units, Bit 20 = 0 units are octets,
             Bit = 1 units are 16 bit quantities
S          : BoS as per {{RFC3032}}
Pointer    : Pointer to the start of the specific ancillary data
             block.
]]></artwork></figure>

<t>The label is recognized by the forwarder as being the trigger for the
pointer behavior. The pointer is the offset from the pointer LSE to the
start of the auxiliary data that is to be used at this hop to process the ToS
label. The pointer may be in units of octets of 16 bit words (or 32 bit
words TBD) as specified by the flag. The S bit had its normal meaning in
an MPLS LSE.</t>

</section>
<section anchor="backward-compatibility" title="Backward Compatibility">

<t>If the LSP includes a legacy node that does not understand the pointer SPL
it will forward based on the FEC of the ToS alone omitting the feature. If that
feature absence results in a service shortfall for traffic on the LSP or MPLS-SR path then
obviously the LSP or path has to be constructed to avoid any node that is unable to
execute the feature. The various methods  of constructing LSPs via LSRs with certain capabilities
is well known routing technology and will not be further discussed in this
memo.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This proposal does not change the security of the MPLS data plane. Normal
operational practice is to prohibit the ingress of an MPLS packet from
other than a trusted source. An attacker that breaches the physical security
of an MPLS domain has many methods of attack by manipulating the label
stack, and this mechanism does not significantly increase that risk.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no IANA requests.</t>

</section>
<section anchor="appendix-1-controversy-alert-use-of-ordinary-labels" title="Appendix 1: CONTROVERSY ALERT - Use Of Ordinary Labels">

<t>Given the restricted number of Base SPLs <xref target="RFC9017"/> it is
interesting to consider whether we might use an ordinary label for this purpose.
At the time of writing there are eight out of 16 base SPLS still
available. This is a dilemma since there is a protocol need for
single label SPLs to support MPLS stack efficiency, but those that we
have available must last the development lifetime of MPLS. On the other
hand using a non-SPL has potential run-time/hardware issues if we need
lots of them. However there probably exists a compromise number
where we can safe allocating Base SPLs but not significantly impact the
forwarder performance with this approach.</t>

<t>The label becomes a run-time constant that the forwarder needs to check during the
parsing of the label stack. This is a 20 bit compare of a run-time constant.
This is simple for a software or microcoded forwarder but needs a
programmable register in a fully hardware based forwarder. Clearly from
a protocol design perspective it is necessary to check the restrictions
on the deployed hardware, but this certainly seems feasible. In deployment
it will of course be necessary to verify that the routers along the
LSP can support this feature before the LSP can be constructed.</t>

<t>If  an ordinary label were assigned to this purpose from the 16-104857516
label set, there are two cases to consider: LSRs that have the capability
of associating a FEC with a label of this value and LSRs that do not.</t>

<t>If an LSR has the capability to allocate a FEC with the chosen value it is necessary
to preallocate this label before  any MPLS application takes that value.
This may impact a number of MPLS applications, but it seems feasible.</t>

<t>An LSR that does not have the capability to allocate a FEC with this value
simply has the issue of adapting the forwarding behavior.</t>

<t>The matter of choosing a suitable value and distributing it is outside the
scope of this memo, but is something that is routinely done in the routing system
so is not a factor in assessing feasibility.</t>

<t>Clearly the LSP needs to be constructed so as to avoid any LSR that is unable to
process a packet with one of these sequestered ordinary labels, but that is
no different to the case where an SPL is used.</t>

<t>The final consideration is what happens if the label every becomes ToS. For this to
happen the packet must have been incorrectly processed, and that is no different
from any other case of a incorrectly processed MPLS packet.</t>

</section>
<section anchor="appendix-2-other-issues-for-discussion" title="Appendix 2: Other Issues for Discussion">

<t>This appendix briefly describes a number of issue that require further
consideration.</t>

<t>1) Pointer labels as described earlier in this document are defined using
an offset that is calculated from the pointer label.<vspace />
An alternative approach, given that we may not get rid of
scanning for the BoS in MPLS header parsing, is to consider
a design in which offsets were relative to the BoS instead. We could
use this as a standard method, or we could specify this
via a flag in the LSE carrying the offset.</t>

<t>The relative to BoS relative approach can be more efficient in
some circumstances, e.g.: When the ancillary data is applicable to multiple hops of a label
stack that is indicating a steering path, such as in SR-MPLS,
the FEC of every steering hop label could indicate to “reuse”
the ancillary data for every hop. The MPLS operation would then
consist of a pop of the ToS label followed by a swap of the
two top labels with each other, so that the following
steering label effectively gets pulled up as ToS.</t>

<t>2) To support pointers being valid across multiple hops, 
the pointer either needs to be indicated either as an offset
relative to BoS, or the value of the pointer in the pointer-SPL
needs to be adjusted by a swap operation.</t>

<t>3) The LSE pointer could include a lifetime indicating the
number of times it is to be propagated. This raises the following issue.</t>

<t>4) The pointer mechanism has to be able to deal with multiple instances
of ancillary data applicable to specific elements within the LSP.
So it is important to know when to stop propagating any pointer
if that approach is adopted (instead of, for example adopting
an approach of one pointer LSE per ToS label.</t>

<t>5) We need to decide of correct name for pointer SPL.</t>

</section>
<section anchor="appendix-3-ancillary-vs-auxiliary-vs-metadata" title="Appendix 3: Ancillary vs Auxiliary vs Metadata">

<t>From the Oxford English Dictionary:</t>

<t><list style="symbols">
  <t>Ancillary: Designating activities and services that provide essential support to the functioning of a central service or industry;</t>
  <t>Auxiliary: Helpful, assistant, affording aid, rendering assistance, giving support or succour(sic).</t>
  <t>Metadata(sic): data whose purpose is to describe and give information about other data.</t>
</list></t>

<t>The two terms ancillary and auxiliary are similar but the additional qualifier that ancillary is <spanx style="emph">essential</spanx> support make it, in the author’s view, the preferred term.</t>

<t>Metadata, the term often used in the technical discussions does appear to be sufficiently descriptive of the purpose of this information that is included in the packet.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC3032" target='https://www.rfc-editor.org/info/rfc3032'>
<front>
<title>MPLS Label Stack Encoding</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></author>
<author initials='D.' surname='Tappan' fullname='D. Tappan'><organization /></author>
<author initials='G.' surname='Fedorkow' fullname='G. Fedorkow'><organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'><organization /></author>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'><organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'><organization /></author>
<author initials='A.' surname='Conta' fullname='A. Conta'><organization /></author>
<date year='2001' month='January' />
<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="RFC9017" target='https://www.rfc-editor.org/info/rfc9017'>
<front>
<title>Special-Purpose Label Terminology</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson'><organization /></author>
<author initials='K.' surname='Kompella' fullname='K. Kompella'><organization /></author>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
<date year='2021' month='April' />
<abstract><t>This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.</t><t>This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator (7) when immediately preceded by the Extension Label (15). </t><t>This document updates RFCs 3032 and 7274.</t></abstract>
</front>
<seriesInfo name='RFC' value='9017'/>
<seriesInfo name='DOI' value='10.17487/RFC9017'/>
</reference>




    </references>

    <references title='Informative References'>




<reference anchor="I-D.kompella-mpls-mspl4fa">
   <front>
      <title>Multi-purpose Special Purpose Label for Forwarding Actions</title>
      <author fullname="Kireeti Kompella">
	 <organization>Juniper Networks</organization>
      </author>
      <author fullname="Vishnu Pavan Beeram">
	 <organization>Juniper Networks</organization>
      </author>
      <author fullname="Tarek Saad">
	 <organization>Juniper Networks</organization>
      </author>
      <author fullname="Israel Meilik">
	 <organization>Broadcom</organization>
      </author>
      <date month="February" day="22" year="2021" />
      <abstract>
	 <t>   A Slice Selector is packet metadata that dictates the packet&#39;s
   forwarding handling in order to conform to its slice requirements.
   There are multiple proposals for carrying slice selectors in MPLS
   networks.  One of the more practical proposals is the &quot;Global
   Identifier for Slice Selector&quot; (GISS).  Global uniqueness requires
   the GISS label be identified as such, via a special purpose label
   (ideally a base special purpose label (bSPL)).  However, bSPLs are a
   precious commodity, and there are many requests for them.  This
   document serves two purposes: to define a bSPL for carrying a GISS,
   and to show how this bSPL can consolidate many current requests for
   special purpose labels while carrying associated data compactly and
   efficiently.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-kompella-mpls-mspl4fa-00" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-kompella-mpls-mspl4fa-00.txt" />
</reference>



<reference  anchor="RFC8200" target='https://www.rfc-editor.org/info/rfc8200'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></author>
<date year='2017' month='July' />
<abstract><t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t></abstract>
</front>
<seriesInfo name='STD' value='86'/>
<seriesInfo name='RFC' value='8200'/>
<seriesInfo name='DOI' value='10.17487/RFC8200'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAHi+o2AAA+1cbW8ct7X+zl9BqB8qNbtbW07SVLcBKttyI0CxBUtpcHFx
ccGd4e4ynh1OhjNab23/93veyOHsrmwrycVtgao1Iu1yOIeH5+U5L+R0OlWF
L129PNN9t5h+o1Tnusqe6R+C1X6hTa2/v7660Vc3F9oE/PO8LlxVmXarn5vO
6Gvv6s62ysznrb07o9HT8/7t9LprVemL2qxhtrI1i246b7em7qbrpgpTA0NK
mGDa8ATTR4/UZsnPq8J0dunb7ZkOXalU6Exd/o+pfA1TbW1QjTvT/9X5YqKD
b7vWLgL8tl3zL4Vfr23dhf9WyvTdyrdnSusp/KMfV4czfTPTT4mW+ClTedPZ
jWm7ne98C2S96Lu+tRvr9K0tVrWv/NJZeNllXcziQLs2rgKS538NPBGvdwYE
7VFwPtPPKrtejwk4r+xbWKptx18+lIKqLzdu+dcC55jBw3tvv53pi+KNbXfW
f+ttW9kQdr586Ou7zv61CLOF6WelVar27dp07s7iPrx+8ezJoyen8uufHz3+
05lSrl7kYy6nz2dv/LqxIGYsLOvQVF8ujDz1zemjR/CUmk6n2sxD15qiU+p2
ZXXTt41nwe1WLui1XXsN/+28Lm0oWje3euU3+srMbQXbbYo3+qLuWliJPgYR
Dye6MLWCUX2wJT5G0om/mCT2voV5QXBRemF4C0+XGuaDeTuggdSlohcEfMGM
CV27sqyAG78DjnWtL/uic74mslsgCnRrbm2tg1vWbuGAik63tgA51qQeNuAv
sIo7eFED+krv4pcRIU1laguEKlOWLe5hbTfwz5awRyBS+HADIumKHhaBC0LK
t/cti5aj8BW8BiCaOQoa3aN26Y0FRauDQ2HtVqbjr4fpcBoFnyz6FqZpdejn
pbuD4UgK8lMH+3Nv64J2a1754k2Y6VuYRJGxgDfBptS+000btw7pSbLiayTZ
dQFIbIGbIJ2873aHipl64Vv6PJg3NAaUDMQKpdd1sIq+KnVr6qXVixZUFSgD
/la70+i+diwJwwtLWETHZnI0lJcD86ydcBsM5+X13dfw6s4C12DnV9YA73DJ
UQBMFTxLwYGdp+3CfYf9dbh6U+lFZZZBweI8sdjVJQhO51sS+J97U7nFlhYO
LAN7hGZe+8a2xL0wQ+GLStK0HjUn0PCeVegogMTYIz1HJgMJRt80tnDw4mvR
M9aj45vrqxP97t29evvhQ1IpXKYWk49Uus6uwwEORr0aFEvNfdf5NY4lmdTH
T/3NyUy/cMCKaosCGYA8EO/OskQi18CMGfhvbbuNb9/oUMD6g4Kxa7NFihY9
PgvUmXllSS1aixM0wfaln8LKAkkF8cUjC5FEVu/G+wqYCCr9FOhZtr4HPXsu
ChKU+ihHULSJ3aQ6aYuAK0nwUXsVkITbgUNun01Q5G9vr/TC2arkTanJN797
J5YVZqY50yxzC/4Hl9YA65Sw7pZYd9ll++5BNpvKOyIH3iivMCGTKwXMz2TJ
kA0DNZpv9RpQxGIbDVMAV1CDsQmikmm+WbR4Bv/pul/PYckw6I3dCjGgBrgw
XgWaArD1XwAeiXOzWJJUHiF5GUGJUlYNNIcoE6gGQivZDDCzyJLC4MJhR/mr
0UvAFK48eYB1X3VuGj0LCQTa027VB+QY/27VsBKxHiwjPP4O/GIUMJz98uL2
xQze99rGvUUv5Jtt1KgLUCjZgMFUJ8VXpCIoHuh5tmP5YSMKr+9Qxdh/sY1D
KS9909FDytRbbYG8mX5Vs8ovyEyiFR9MDL2JtmIDrBZpKdWxKBboDnolF4o+
oFXT877Tl+hEUfSCtWhhaTMt7+UJzYMM6zM/vTCg/K7bZosdVLZy4CPAcYA8
AUvaaLbYS2R2y0TJ3bNbNW4D7vyg1cAMddAg7Vry5NejM6eXR0nFlepo29De
+PqnviZ50hvXrdhsjK2zSmI+IZaLN8KN7En+QJEWoCKwb2x+YMzwEewf6ZwK
fbFC6gEU0/Jk/ijA6DWjdx0WeMfj0df71iqmLL1lIDaROEPzJrEAy3KIkB8s
3DVAfuf7gGLQgQ8r2X1FMdGZ8bpnU9hQs6UCo8TbAWMUST8SylGHBf1Cx+Vb
XhBJxUx95zeAiFpy5BsSctM0ll0uiju8p7wDS2SWrHsIAEDi6qW8JsETVGMh
db0rE+pemQAPNNOsb3v+i4SehMMUBQAylDV4CfAm/hWiCm9gIC6D5qS9DBo8
Jm5lGj7TDHHTesi0lp73GwloLRlKGjRP6rRwbKB2CUTp9KCsAXU1Cs1m5ask
6TfiTQGVw/6OxmXwNmoAmEIENneI0PRL0d1rph427QcET8cvr384iUuiudza
TtSAS1GOFoO2IR9KaxvgMSzsfFhUNOqblUMlGK8MedE0IB9kccW9rsD97XJU
mCWGaNhxIFdgnXyC0Ay2nJUE4SHpawMUwjCgPqBVEs43ML8BohxK+Yp0Flal
l7DDLdgLFIEIAoG8aE/AbhS2IU2ApfQY03RsUd69e3H5N8YOTdd++ABP6Pjz
xfS+ny9k0NVj/Z5/uyX/LzEP/7zXD5rqNE4l+k+SGqcaDf34fPzAMPS9vu/n
/e7Q2b1DZ79i6AMIePiynibUmli/M+u3H/85OOtOEuYgrb8Ns/6ys7GfYtbn
idS7M/27XK41ZZ2+PRJPc1lP2QBQfCtaePSB5iYriK6CjdDx1eMT0qpcKo+v
Tk9QWcGU664HZVXJGUdkqo/EELBxZJed0PiLAVNe/Ny7O1ORL31WGXjg+MXF
s5MYaw6UsFHCVEJ6mYLhDrNXRYpN8/iVF0ZuMqE4NDT4WljGESD00lJwA8oH
pgGX1kLU7FpC3xFpIv4He7HiSJxc6wVaGHQtxI0LCtDSkwqMMz4E8faPK1cF
XnIG+mhCGg0zkM2DGXEmDJrQUzuw5o4IA4i3zpMWE56L8m5gy9Zm6Wqb+Npy
3DUX7K02/BEibLKosoXET2RjVeHYSArmmdQVmNw+5LkHnoycaNoRQRQR+WF4
udVvwBXOVMxk4EOTndCr8h7C9hSRxb1Afhy7mZ3xePyTcct6bUsHlhoZ0YOX
t2WIJEB4pS4XPA4fiBSlRQJhk1HsAqjStigchA04bVaBCCwg6qszbAZbXE52
KGQJdGF3/vHy+hjgHxZCJUIYZyAcNAiwwPhDuYQZ6b166WPovRnkKs4mOIGc
53bIq+EQENWoHqT2E3bsylQgWGEXSItRSLEiu/W1KWU7QSyAcIlJYGEkY/h2
UPKehHZI6kWlLRQmIuhNskx6CTj3beUB1uLmjx+gzMV+4mLG/hwn6duaUzpr
a2oJUAYcj/pHVCVihu92saRfN4Da6w4UlqcXOJLoFLwTk2KCTEqLislhDcAz
ygoG38AEHQ6mrOXKAIDH4EQxlnKEQYCzCE8Ia+Hc2/uJGxGOi5ows9TwaYrk
7HItq4CggiPdVykddQYWvKHMJlrzm43hP5T6cUexGxhmy0kyAbzsmpWPYP8S
YGjNwdx25BdyhR2Ux3Uov5f8krkJsLlsHMzoYTJHIr5zK2RorEosBxG9xYgg
5jiiAYuJBvw/s5mzkWs7egHtIqdikklkUwj0EXmYgaDJJloNjmCs5JS0bujD
0eR7dIJdDfCaEBUbOTgE4IkCV7P+h6SiSLe6zs0MxpQUyiLyZVsEEyWJkoXB
Ks4pmMMYdu3+QRvHoRsyao3BGcSsgUI1j9IDO6CChY0eRBXcE4fAiZkT3Tdk
x5qUF4fVTWjzQz/nNHO3v5VojFDKMACLbKkBmmtw77yIqG7kXygWaVwxwuXw
UpxjbmH19sMHEt3RN2YB7wTUnoDRb4fe///B+9WTDA6+RNahpxvBwV+Ana++
zGb9Eawmhca/dlb975DgXyMkGKlUjAue8l/gIfSUfMOAPc40BAYP0gWS2iSu
xy/thgDbLgceolUH9OqXa9U/gfz/W1X+hVSFfEzUlHP6435FETQF3iz3wilp
Zjm0aO0IUBmE052rsyhZIKgZI4/SwtvXGPJhbMeZ1ZFqhFUsRezjJ8wMk+cG
JBGfBnAwPBLdtbrHX3NmlrZDYVGDYSxnDbkLQJLkljkgwAefF2yTQrsGS7Cl
hEtjrNNinLYyTaDqMUc1cd5SpSw+5dkXtCjKeVNSufAtoC6AKxQ/YZFqps8r
mLuOeVaTZqcaFdehlLxmQSVGiprnOPTo9vbqKNIAoZovHOH6xJ9RRE3pct5R
qinnrIAQbOoXU8yF5lvtOOeZivhdX27zksD3ESUONQFifOvnFYRHLD3BV3cI
mgL1XmD6tm8a33Yqw5gArTBhATjtONgOsebJXl6XdktRwMPFc6rk8VyUDE8R
x/EQpE70q/Pvte2KEzWUvg/yaieQQ8R9ef1HrNpPDqSYbV14bmZgRnPIxXSp
btX6frnaaXK4iLV//R0NC/r44jusYAOH6TWKqrjY3gJQsrQL0CMQAzT/gHov
vtPdtkHoTygb5hN8vSZwrbLQVLLXtS9jYQywM6HqPOd18Z2S4qXDnDeVDrkB
IyWxswiBw9DKvqWEN0qvpGWoGwT4rai/gfkQOBuT9jd1PQiDqFpBRTMiARa4
1a1bupLZGoNAWHJK1+HmYpGg42gW01sgiJcQnMCMuNoKjFmXJfgpFvBDlkxU
YTIOcYkrkpx3/+BSlZn7OxtT8kFjCZ6sHanCbrJKmlaARdg5gHHeApgUrQ5q
aQwzMzHJI3N4sOrLYb5R+KdEGXYEcFcGxAI0vsMqKeU4qCLJ9YpBL6SKPeMs
akugapK3fKQXm/InU+yETUHH1AOWo6R3JKU2MKLMWQ/RXOBWn1GgDtIFsddo
1r1cGofmbMe1Ok9WbG2LlaldWOs8SZMXo4AA7DECMpVU8GFRbI/3Ni5Pi2BG
9Fiqoif6HqarvFprsMIO0rrVfv6TLToSWNgGh+aGPwLTXqfxwCxwZJt6p6Yj
3QW/dWXnnyk2vHfW9w+cWT8Md+qH4blfNfyBxPyypd4PhvXDAPHB2e8Hxb+K
M58Exw+bXT9s9h3h/T8oXiUF3ilhJWQ0rmVFnIRQ/DwcKvCSYesog9famACU
dimqZaXmNgRuinJT7N5HfVcfL28NiBfNtrq3gPWr6lfhaKJcVm3JWwfACV49
noDtgX9PqAkyLo7iB4O9cYQhrJP+DHUU2++OeJLJoR6SnfoH+T9+ZVrTDTV+
AAVKYFxPbZYlt6YdNM7YVRcx8FCfD3FpjfRbAMDGyCmuOZp+cC6KM+NXjtzE
1U8T2lBy4ntQdOMHbEEUyW7Bw1102gm9i/e0b23Rc/p/oWCggIpRO+eOgj8m
Uk6pO1jlzwN5B5/f6e09peef5F7r084GvJb+PL/1GY7rEwbg8+bSmeID45A6
5Df9OSQzc+uh8k+ic9uzJwep/dT4HWP4UD/xUDf0UFv+EHpAiD7Ny336P86f
HcTwifFfPJD+9w/kz/74j/N/f/xD6fk4ENgf/ykccGj+PTPB3/wFub8rn5/i
j37genfHv98j5zR+8xeWhs+2Bjzb59PyUSqeZFR8oR9sjmb3/xycCz6/d66H
A5XTiFReiEe7ED/1eajlNuVvhpAqD+d2WxOyvpJxIMiV5TM5ueOzTGVqRkVw
kuchbWxrSXXp1EHQuTZCCFjHfnxp2DHTeRE8BDDRiov69zRyUFUYKSvtwmDa
oaEOQqmXxwJiVmz9KAmHq8TnIR1LKgEMtJXD/ITZq5HiawCg9IWAPExUCBzL
gt/J+JWYE8BjF5xrMILT+ERATL5it7aTFMqoFsqdFtSjIKG2NIVS1E+r55TI
wUI2ojtJHHNOeZTT4M4jTadyDMXDLGlEQSYEh5uDQuzrijgPXjbZ2wBCfngi
o5lIX/Dcqk9Ue1P2GNNKSWwneu3ewkNcw0cposSQu6Pu0lTQp2TteMvbxGZa
CbZqI1f5G6EFO7Ao0a1EkrD3FNkwzprnOqAiTKcOYuydTceeBiQJPP499cA0
PtAykujS+tTv9PPsO3l+bOSk3Xic+FwD9OWWrLW/owYSrtJRaktaZZAoarzB
9mKZmk51ln5tXB1PPBl6DkMcztSElNemzVxSXub6guT4TQ2iJlPlje2YDx5T
mFqgsxDnqefzqwVJW8p6Dx0PpU/1AFiiqTEzl53d4lMDGxAuOj5CFvHv1y9j
y28+PdVKgpySimdGpDnr/v78A9nnOPerYe7sKOI9zUfSYyQmhcF7ub/Pu6+i
jaYdxeaKQ2Ni115rUz94zAZz4p4LHmRdZdXSBuQ6Jc9iai09RX2K9Ep8kpRn
OEAz33Z2fDZiorEvnBK3Kh2ES/m3lpNuWWQqaxoOBmKo8nOPoXG3PcA3Dnc4
7bw9KI/pAT57Q3tBGuklPJWvR8WrLgl6dsAk0xUF/LLVAlVGdIVc03AQJ562
nOkbPO2Rx95kg6MAg3GTiC0VJHZWyF4AOC0OL1WuglngdmbHEuryj/B+0XAq
9tzkBywPWYlPnMCUBaLvZ4dBq8wP6XJL2Og90f5Rn5iiLLBk7Ie3cX47Mlfa
LA+lWRH3TOH7Icv66ABGe3zgs9MDnz2JUzyGr5/oL/VX+mv9J/2N/vNDPlMM
337l/2iWvbiDm+v2fiAeq5b6/Q2OzyOn978RLczb7OVn6C3xoFjI0AqnoVq3
XFIWPitTRifF8yCtxy/wIN/JmX4W58kPDcopP5yvAGmLx11lugElPwV5P310
pm8EOcX34ZFesDT8tf4WdoU+IZX1RWfhS6V3f3D0t7Clw9DHX1NKSQwMFuNw
3M3wyBk5CUMdvvlRTRqXbcRZ+kMMBSCjwb+n+t5OJmaPQjp+PBvD/6gBEfzn
uB41h6B92iJQo9YWflkDw/aPGGoTu24pV8k7GUG72t1MhtHxU8c77hcLRInp
aG2uw7x2NVq76d+6yo0dnYuQiA/yyRF0POmzU+kEuK2koS8nRRwTWAreSngV
bzr+Jnu68S14AiwNPTmlc2n8we3T5yfIhQGLRR5RSf82pRnxTBzOzd3cVC/j
g6oqu1ljOESM/AVRXzdg5DmnqLiLHGHz9ZCWM7qyS1Nsqcarxwd+e7xAgq7M
GHEWcKSKrZayk9jsijhtrw2CTuJV1MGwdl3CLAtr0OxiTzq9U8kHeAsDYZlR
vTjY9g6PboI9bruF4deCtBgs5MaX4qoEU01vXoNjZGheKz+PJwuzYfQ1HpXn
fcd4knyBRIR33pXkwQeugED0tRy9lSynHa8F9+oObAe8LHl+5EOanE8AXAd9
5wz88lrS4/FoeUr/ot5jcGRhpQhYAeCA0yPexRsztgRE2HVzIBazykO7ekzs
k1skwbgBqlsELs/GhdSdo6hJALBIuoz1AHk0w+HZfREz/ZLkcmiNQNiK92nQ
mdsgirRycz4WDsQxLs9uhpGSNl2d4LvhEArsNAQLeEWC79vCUjHUdBjpxRsj
5i0mwAWnNqttAHxcJZJV9g6OHGjn1zlCwyE0JZ1AB9Vq6MBifkpRSWzM6kBw
IxaRE8Oy8yt0oJkr+Uxk68IbAkGX5y/PD+9AuhMD6as9j8TuCBs6PkB73hBI
fqsfgyN79fL29au/X7y++U99fnXx+lZPqZvm1UK/ivcLkAeF6f/GjewEz0EY
ufl4cH9PTTyRTj4Fb1P58EFgcrw7Qtog0nmZiE3xCgS3XHWU3cd8w/hugwRB
Y8uAOmcJwCOb1HjQushowbiWphMgi+ZTqLsBLwYSr9Ip+NgxEag3AS+poSYN
zm60Vo6xtL7zhReMi/0l++fqh1YiFhPOI1i0Lw5DgwklOLhtno+lWEWlsuFA
PgW0lZGzKnK9Cm1m5RY2LhZnx3Py7LooXl/xiWE+iFX7mg6VowCkJgzd9vUU
Z/jjCmzthhJQIfTYFbFA9tP1DpXvYmP9eqblOLPwAbuoDJ7CsG9d6IK04ICe
uRDDJTlBteEDLojlKS8jceYgH8iHA5IOfqaglavBt8shJKr5SaaEmwOpJWiW
owS+WgIJi0tlq4mX1xy42CJlMUDpYZ/KPp5eULGlaD+plcsKQLQ5Xdiypgsg
6Mzu3ovjAZwQj+nKmV2/6GgLsMnDFQAOqHtrII44RAQaPKC/bA2IJUpIa5fA
fW42M5rvC0kbyg40u3vhWWXpGLPcJJOkWOIvYC5Cho7OSXPR0iJMQcVLjMn1
ncyM+EoItSu/xRNN8voo31iETPcx4Im8gO6NDxhjGxs/iFKdEAA5uL4F+Zjb
MQ0gf4yjZf/QifERaC+7hc6YxE10j69wECiQZYTiuLGnnhGiOWByNmRIAnVG
lQwCB/szIMXHX08fP/rym6/+9NXjr1WqJk8yQ4QVVE7XZYbvjF131g23slnp
lryN5M9YpxEOkfzHAnKMV+9M1XNGYZixpMwqL41uZHnNMGX0Di2NZJR/yl5A
o9BI1TL3jmRQbrC16dGO7/dgDSRuE+jZOwnGLVhEH80rqoGwVzQ/j6V2Hw8s
XVQqH0kUxOK8wjHsPMDU+xcc2ajkPFVkFhlI0uzSNAPuHI4cpqCC7dCabzlB
aV55L9Y49K4j1R12CntaWzdnOMbszRISaj8hIYvnLly6MSLhSUZ1mDQpESFL
viVivbAFY7FWwQ8dCQtgNV87g3lRbo9jbkrXgIpWI2pNnu/NQS7MyuB3gLpp
I0ZIN0Y/JsIzzurXMUETLHemBup82NHEEO0Kzarq/ISfxKXxxC2l1uKVFX1I
TRQLt1fvwREb1j5EQyHe9MCCbKkHNDoUqo+8iBAE1sPPSO6MFkSOm2SOrhwB
+ICt1UWX57Ii6ovtIcM6FJkT5B9DVloPOZSDE+VIlzF5QnSnZ/oVTXHJvh3d
zfN0H44gRBNHz1tnFyg5KUebqyBLP8NObq6N8YEasRJIeHySgvfYIXSgmJRa
URJERfvIncWCXjAOlWA8MgpQOF+jVe7H5xJGa7QBZmhcT/hgEg9fMtxKJ8aX
FqF0SVdQxZtEYpUPcyNOkL40dgsgmEgMElevUiIzFV6Y9sDeI+ano5jyzFTf
mukfLd+DpPieFyct+RQpYzDMQQUncGVoumiEIjKM/wxF+FHpOTUv+eghrZFS
6gM1T+m8ZTVmVvSOlBqPsBUrcorvp3It7JqcvpxoO1vOznQ6DfvRW0/yetvK
Nxwp5QFR2uysLIG8sJZAGQbaEx2vGILV3rye4v5MVJYpYJ1Nz2DihZWZeTeU
Wrw+avGmqyN1gHBK89NMMAGH4yQJWSGQpqOsAAlC6OJ9Lc3+LQxceOaEjJGS
IheKEBZ0kUYJ4rmNGjVsknLjXV6+Vml5YqfAgBRSAllaKndUFepSg4xCu6XU
6YnOiuSpbskZM/BJaLkBgYJ5Hu3RRKtc06TxLXcF6ZRJ6orjUjEJndoRNxLk
bhW9YKyexTRcnf+JwYsaHfgpf+LgPeNiM1ifJye0Tyj+6Xi/7Dk3s5shfBrX
vbJ70vDbIM6Y34qpDLPEBQrsb42LVxZkx7XRSgIRX56Ms3kprh8SRFEX8BYN
3vD9Y81qvxw0VqSUdrUVHXYI+TUB4K1n6sbLMgDMwJYb9pNUtORbKWASlLy4
vlhoinlqJ/dE5JcHxZvajl064jC+LowGiAFPD2IKsx5nUzHlnNQD2PbVCVrC
VPqEtZWWwwFye3QVLL0oSxyOkxhPzrIi0F3Q5yk3C398bztDWWn1IvqOV29h
ulJfQPjuwgq8I4U1MJ6KtWmqM/1cWhXi3YJ3lFQjJy7JRIGz0uav0TlzrJ1i
ETb8C7mETYJKiJxhXEvZJU5KEh4rsZFz+x+KbpeKizjT39mqgThvkrpfIbow
i4WXSw8d+IgW21D4FpbUIUuujyBgPJLUUjMJhFnHwRUnM1xtZA99ciZXcVGC
IgY6O9fV4uKXfK3WUPwzc0qzcOZwqOGShbPtOr+NjI4lpA2i1gOpbDPGG138
wneGupigG2YBov6QmP2HoQEIj+w7YE8sOtK9L7/HVKndcFcGBC4AuRBkImVA
aOQAf40fwg51oCV9GKqXlDGldOBwt2DgWGN0wVvoo9dMoKohGxjN3c6FwDkT
Bw84rpxGmPe/xbur/xxbAAA=

-->

</rfc>

