rfc9889.original.xml   rfc9889.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.27 (Ruby 3.3. -ietf-teas-5g-ns-ip-mpls-18" number="9889" updates="" obsoletes="" xml:lang="en"
6) --> category="info" consensus="true" submissionType="IETF" tocDepth="2" tocInclude=
<?rfc compact="yes"?> "true" sortRefs="true" symRefs="true" version="3">
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <!-- [rfced] We updated the abbreviated title (only appears in the running
-ietf-teas-5g-ns-ip-mpls-18" category="info" consensus="true" submissionType="IE header in the PDF output) as follows to more closely align with the
TF" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true" version="3"> document title. Please let us know if you prefer otherwise.
<!-- xml2rfc v2v3 conversion 3.28.1 -->
Original:
Implementing 5G Transport Slices
Updated:
Realization of Network Slices for 5G Networks
-->
<!-- [rfced] This is a question for Luis. How would you like for your initials
to appear in the first-page header? For now, we have updated to
"L. Contreras" per the format used in the most recent documents you have
authored, but we see that some documents use "LM. Contreras" in the
first-page header.
L. Contreras - RFCs 9543, 9439, 9013
LM. Contreras - RFCs 8597, 8568, 8432, 7161, 7028
-->
<front> <front>
<title abbrev="Implementing 5G Transport Slices">A Realization of Network Sl <title abbrev="Realization of Network Slices for 5G Networks">Realization of
ices for 5G Networks Using Current IP/MPLS Technologies</title> Network Slices for 5G Networks Using Current IP/MPLS Technologies</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-5g-ns-ip-mpls-18"/> <seriesInfo name="RFC" value="9889"/>
<author fullname="Krzysztof G. Szarkowicz" role="editor"> <author fullname="Krzysztof G. Szarkowicz" surname="Szarkowicz" initials="K.
" role="editor">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<city>Wien</city> <city>Wien</city>
<country>Austria</country> <country>Austria</country>
</postal> </postal>
<email>kszarkowicz@juniper.net</email> <email>kszarkowicz@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Richard Roberts" role="editor"> <author fullname="Richard Roberts" surname="Roberts" initials="R" role="edit or">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<city>Rennes</city> <city>Rennes</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>rroberts@juniper.net</email> <email>rroberts@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Julian Lucek"> <author fullname="Julian Lucek" surname="Lucek" initials="J">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<city>London</city> <city>London</city>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>jlucek@juniper.net</email> <email>jlucek@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" role="editor"> <author fullname="Mohamed Boucadair" surname="Boucadair" initials="M" role=" editor">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Luis M. Contreras">
<author fullname="Luis M. Contreras" surname="Contreras" initials="L.">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<postal> <postal>
<street>Ronda de la Comunicacion, s/n</street> <street>Ronda de la Comunicacion, s/n</street>
<city>Madrid</city> <city>Madrid</city>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>luismiguel.contrerasmurillo@telefonica.com</email> <email>luismiguel.contrerasmurillo@telefonica.com</email>
<uri>https://lmcontreras.com/</uri> <uri>https://lmcontreras.com/</uri>
</address> </address>
</author> </author>
<date year="2025" month="April" day="03"/> <date year="2025" month="October"/>
<area>Routing</area> <area>RTG</area>
<workgroup>TEAS</workgroup> <workgroup>teas</workgroup>
<keyword>L3VPN</keyword> <keyword>L3VPN</keyword>
<keyword>L2VPN</keyword> <keyword>L2VPN</keyword>
<keyword>Slice Service</keyword> <keyword>Slice Service</keyword>
<abstract>
<?line 174?>
<!-- [rfced] How may we update these sentences to improve readability of "5G
slicing connectivity service objectives" and "currently commonly"?
Original:
This document describes a Network Slice realization model for IP/MPLS
networks with a focus on the Transport Network fulfilling 5G slicing
connectivity service objectives. The realization model reuses many
building blocks currently commonly used in service provider networks.
Perhaps:
This document describes a Network Slice realization model for IP/MPLS
networks with a focus on the Transport Network fulfilling the connectivity
service objectives for 5G slicing. The realization model reuses many
building blocks commonly used in service provider networks at the current tim
e.
-->
<abstract>
<t>Network slicing is a feature that was introduced by the 3rd Generation Partne rship Project (3GPP) in mobile networks. Realization of 5G slicing implies requi rements for all mobile domains, including the Radio Access Network (RAN), Core N etwork (CN), and Transport Network (TN).</t> <t>Network slicing is a feature that was introduced by the 3rd Generation Partne rship Project (3GPP) in mobile networks. Realization of 5G slicing implies requi rements for all mobile domains, including the Radio Access Network (RAN), Core N etwork (CN), and Transport Network (TN).</t>
<t>This document describes a Network Slice realization model for IP/MPLS n etworks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks.</t> <t>This document describes a Network Slice realization model for IP/MPLS n etworks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks c urrently commonly used in service provider networks.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Traffic Engineering Architecture and Signaling Working Group mailing list (t
eas@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
teas/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/boucadair/5g-slice-realization"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 181?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document focuses on network slicing for 5G networks, covering the connectivity between Network Functions (NFs) across multiple domains such as edg e clouds, data centers, and the Wide Area Network (WAN). The document describes a Network Slice realization approach that fulfills 5G slicing requirements by us ing existing IP/MPLS technologies (at the time of publication of this document) to optimally control connectivity Service Level Agreements (SLAs) offered for 5G slices. To that aim, this document describes the scope of the Transport Network in 5G architectures (<xref target="sec-scope"/>), disambiguates 5G Network Slic ing versus Transport Network Slicing (<xref target="sec-5gtn"/>), draws the peri meter of the various orchestration domains to realize slices (<xref target="sec- orch"/>), and identifies the required coordination between these orchestration d omains for adequate setup of Attachment Circuits (ACs) (<xref target="sec-tn-nsi "/>).</t> <t>This document focuses on network slicing for 5G networks, covering the connectivity between Network Functions (NFs) across multiple domains such as edg e clouds, data centers, and the Wide Area Network (WAN). The document describes a Network Slice realization approach that fulfills 5G slicing requirements by us ing existing IP/MPLS technologies (at the time of publication of this document) to optimally control connectivity Service Level Agreements (SLAs) offered for 5G slices. To that aim, this document describes the scope of the Transport Network in 5G architectures (<xref target="sec-scope"/>), disambiguates 5G Network Slic ing versus Transport Network Slicing (<xref target="sec-5gtn"/>), draws the peri meter of the various orchestration domains to realize slices (<xref target="sec- orch"/>), and identifies the required coordination between these orchestration d omains for adequate setup of Attachment Circuits (ACs) (<xref target="sec-tn-nsi "/>).</t>
<t>This work is compatible with the framework defined in <xref target="RFC <t>This work is compatible with the framework defined in <xref target="RFC
9543"/> which describes network slicing in the context of networks built from IE 9543"/>, which describes network slicing in the context of networks built from I
TF technologies. Specifically, this document describes an approach to how RFC 95 ETF technologies. Specifically, this document describes an approach to how RFC 9
43 Network Slices are realized within provider networks and how such slices are 543 Network Slices are realized within provider networks and how such slices are
stitched to Transport Network resources in a customer site in the context of Tra stitched to Transport Network resources in a customer site in the context of Tr
nsport Network Slices (<xref target="fig-end-to-end"/>). ansport Network Slices (<xref target="fig-end-to-end"/>).
The realization of an RFC 9543 Network Slice (i.e., connectivity with performanc The realization of an RFC 9543 Network Slice (i.e., connectivity with performanc
e commitments) involves the provider network and partially the AC (the PE-side o e commitments) involves the provider network and partially the AC (the Provider
f the AC). This document assumes that the customer site infrastructure is over-p Edge (PE) side of the AC). This document assumes that the customer site infrastr
rovisioned and involves short distances (low latency) where basic QoS/scheduling ucture is over-provisioned and involves short distances (low latency) where basi
logic is sufficient to comply with the Service Level Objectives (SLOs).</t> c QoS/scheduling logic is sufficient to comply with the Service Level Objectives
(SLOs).</t>
<figure anchor="fig-end-to-end"> <figure anchor="fig-end-to-end">
<name>Transport Network Slice &amp; RFC 9543 Network Slice Scopes</name > <name>Transport Network Slice and RFC 9543 Network Slice Scopes</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="320" width="520" viewBox="0 0 520 320" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="320" width="520" viewBox="0 0 520 320" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,144 L 8,288" fill="none" stroke="black"/> <path d="M 8,144 L 8,288" fill="none" stroke="black"/>
<path d="M 24,208 L 24,240" fill="none" stroke="black"/> <path d="M 24,208 L 24,240" fill="none" stroke="black"/>
<path d="M 56,208 L 56,240" fill="none" stroke="black"/> <path d="M 56,208 L 56,240" fill="none" stroke="black"/>
<path d="M 88,208 L 88,240" fill="none" stroke="black"/> <path d="M 88,208 L 88,240" fill="none" stroke="black"/>
<path d="M 112,144 L 112,208" fill="none" stroke="black"/> <path d="M 112,144 L 112,208" fill="none" stroke="black"/>
<path d="M 112,240 L 112,288" fill="none" stroke="black"/> <path d="M 112,240 L 112,288" fill="none" stroke="black"/>
<path d="M 128,208 L 128,240" fill="none" stroke="black"/> <path d="M 128,208 L 128,240" fill="none" stroke="black"/>
<path d="M 184,80 L 184,128" fill="none" stroke="black"/> <path d="M 184,80 L 184,128" fill="none" stroke="black"/>
skipping to change at line 207 skipping to change at line 233
| | +-+--+ +-+--+ | | | | +-+--+ +-+--+ | |
| +---+ +--+-+ AC | | | | AC +-+-+ | | +---+ +--+-+ AC | | | | AC +-+-+ |
| |NF +...+ CE +------+ PE | | PE +----+NF | | | |NF +...+ CE +------+ PE | | PE +----+NF | |
| +---+ +--+-+ | | | | +-+-+ | | +---+ +--+-+ | | | | +-+-+ |
| | +-+--+ +-+--+ | | | | +-+--+ +-+--+ | |
| | | | | | | | | | | |
+------------+ +---------------+ +------------+ +------------+ +---------------+ +------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This document focuses on RFC9543 Network Slice deployments where the Se
rvice Demarcation Points (SDPs) are located per Types 3 and 4 of Figure 1 of <xr <t>This document focuses on RFC 9543 Network Slice deployments where the S
ef target="RFC9543"/>.</t> ervice Demarcation Points (SDPs) are located per Types 3 and 4 in Figure 1 of <x
ref target="RFC9543"/>.</t>
<!-- [rfced] Section 1 of RFC 9543 notes the following:
It is intended that the terms "IETF Network Slice" and "IETF Network
Slice Service" be used only in this document. Other documents that
need to indicate the type of network slice or network slice service
described in this document can use the terms "RFC 9543 Network Slice"
and "RFC 9543 Network Slice Service".
Based on this, should "IETF Network Slice Service" and "IETF Network Slice" in
the sentences below be updated to "RFC 9543 Network Slice Service" and "RFC
9543 Network Slice", respectively?
Original:
Mapping
considerations between 3GPP and IETF Network Slice Service (e.g.,
mapping of service parameters) are discussed, e.g., in
[I-D.ietf-teas-5g-network-slice-application].
...
Data Confidentiality and Integrity of an IETF Network Slice: As desc
ribed in Section 5.1.2.1 of [RFC9543], the customer might request
a Service Level Expectation (SLE) that mandates encryption.
-->
<!-- [rfced] We have a few questions about the sentence below (which is also
mentioned in the question above).
a) How may we revise "Mapping considerations between 3GPP and IETF Network
Slice Service" to improve clarity?
b) Is the second "e.g." needed?
Original:
Mapping
considerations between 3GPP and IETF Network Slice Service (e.g.,
mapping of service parameters) are discussed, e.g., in
[I-D.ietf-teas-5g-network-slice-application].
Perhaps:
Considerations regarding the mapping between the 5G Network Slice Service
and RFC 9543 Network Slice Service (e.g., mapping of service parameters)
are discussed in [NS-APP].
-->
<t>The realization approach described in this document is typically trigge red by Network Slice Service requests. How a Network Slice Service request is pl aced for realization, including how it is derived from a 5G Slice Service reques t, is out of scope. Mapping considerations between 3GPP and IETF Network Slice S ervice (e.g., mapping of service parameters) are discussed, e.g., in <xref targe t="I-D.ietf-teas-5g-network-slice-application"/>.</t> <t>The realization approach described in this document is typically trigge red by Network Slice Service requests. How a Network Slice Service request is pl aced for realization, including how it is derived from a 5G Slice Service reques t, is out of scope. Mapping considerations between 3GPP and IETF Network Slice S ervice (e.g., mapping of service parameters) are discussed, e.g., in <xref targe t="I-D.ietf-teas-5g-network-slice-application"/>.</t>
<t>The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice <t>The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice
identification <xref target="TS-23.501"/>. Because S-NSSAIs are not visible to t he transport domain, 5G domains can expose the 5G slices to the transport identification <xref target="TS-23.501"/>. Because S-NSSAIs are not visible to t he transport domain, 5G domains can expose the 5G slices to the transport
domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or
Layer 4). Passing information between customer sites and provider networks is r Layer 4). Passing information between customer sites and provider networks is r
eferred to as the "hand-off". <xref target="sec-handoff-domains"/> lists a set o eferred to as the "handoff". <xref target="sec-handoff-domains"/> lists a set of
f hand-off methods for slice mapping purposes.</t> handoff methods for slice mapping purposes.</t>
<t>Unlike approaches that require new protocol extensions (e.g., <xref tar <t>Unlike approaches that require new protocol extensions (e.g., <xref tar
get="I-D.ietf-teas-ns-ip-mpls"/>), the realization model described in this docum get="I-D.ietf-teas-ns-ip-mpls"/>), the realization model described in this docum
ent uses a set of building blocks commonly used in service provider networks (at ent uses a set of building blocks commonly used in service provider networks (at
the time of publication of this document). The model uses (1) Layer 2 Virtual P the time of publication of this document). The model uses (1) L2VPN <xref targe
rivate Network (L2VPN) <xref target="RFC4664"/> and/or Layer 3 Virtual Private N t="RFC4664"/> and/or L3VPN <xref target="RFC4364"/> service instances for logica
etwork (L3VPN) <xref target="RFC4364"/> service instances for logical separation l separation, (2) fine-grained resource control at the PEs, (3) coarse-grained r
, (2) fine-grained resource control at the Provider Edges (PEs), (3) coarse-grai esource control within the provider network, and (4) capacity planning and manag
ned resource control within the provider network, and (4) capacity planning/mana ement. More details are provided in Sections <xref format="counter" target="sec-
gement. More details are provided in Sections <xref format="counter" target="sec over-rea-model"/>, <xref format="counter" target="sec-qos-map"/>, <xref format="
-over-rea-model"/>, <xref format="counter" target="sec-qos-map"/>, <xref format= counter" target="transport-plane-mapping-models"/>, and <xref format="counter" t
"counter" target="transport-plane-mapping-models"/>, and <xref format="counter" arget="sec-capacity-planning"/>.</t>
target="sec-capacity-planning"/>.</t>
<t>This realization model uses a single Network Resource Partition (NRP) ( <xref section="7.1" sectionFormat="of" target="RFC9543"/>). The applicability to multiple NRPs is out of scope.</t> <t>This realization model uses a single Network Resource Partition (NRP) ( <xref section="7.1" sectionFormat="of" target="RFC9543"/>). The applicability to multiple NRPs is out of scope.</t>
<t>Although this document focuses on 5G, the realizations are not fundamen tally constrained by the 5G use case. The document is not intended to be a BCP a nd does not claim to specify mandatory mechanisms to realize network slices. Rat her, a key goal of the document is to provide pragmatic implementation approache s by leveraging existing readily-available, widely-deployed techniques. The docu ment is also intended to align the mobile and the IETF perspectives of slicing f rom a realization perspective.</t> <t>Although this document focuses on 5G, the realizations are not fundamen tally constrained by the 5G use case. The document is not intended to be a BCP a nd does not claim to specify mandatory mechanisms to realize network slices. Rat her, a key goal of the document is to provide pragmatic implementation approache s by leveraging existing techniques that are readily available and widely deploy ed. The document is also intended to align the mobile and the IETF perspectives of slicing from a realization perspective.</t>
<t>For a definitive description of 3GPP network architectures, the reader should refer to <xref target="TS-23.501"/>. More details can be found in <xref target="Book-5G"/>.</t> <t>For a definitive description of 3GPP network architectures, the reader should refer to <xref target="TS-23.501"/>. More details can be found in <xref target="Book-5G"/>.</t>
</section> </section>
<section anchor="terms">
<name>Terminology</name>
<section anchor="definitions"> <section anchor="definitions">
<name>Definitions</name> <name>Definitions</name>
<t>The document uses the terms defined in <xref target="RFC9543"/>. Specif ically, the use of "Customer" is consistent with <xref target="RFC9543"/> but wi th the following contextualization (see also <xref target="sec-ref-design"/>):</ t> <t>The document uses the terms defined in <xref target="RFC9543"/>. Specif ically, the use of "Customer" is consistent with <xref target="RFC9543"/> but wi th the following contextualization (see also <xref target="sec-ref-design"/>):</ t>
<dl> <dl>
<dt>Customer:</dt> <dt>Customer:</dt>
<dd> <dd>
<t>An entity that is responsible for managing and orchestrating the en <t>An entity that is responsible for managing and orchestrating the
d-to-end 5G Mobile Network, notably the Radio Access Network (RAN) and Core Netw end-to-end 5G Mobile Network, notably the Radio Access Network (RAN)
ork (CN).</t> and Core Network (CN).</t>
</dd>
<dt/>
<dd>
<t>This entity is distinct from the customer of a 5G Network Slice Ser vice.</t> <t>This entity is distinct from the customer of a 5G Network Slice Ser vice.</t>
</dd> </dd>
</dl> </dl>
<t>This document makes use of the following terms:</t> <t>This document makes use of the following terms:</t>
<dl> <dl>
<dt>Customer site:</dt> <dt>Customer site:</dt>
<dd> <dd>
<t>A customer manages and deploys 5G NFs (e.g., gNodeB (gNB) and 5G Co <t>A customer manages and deploys 5G NFs (e.g., gNodeB (gNB) and 5G
re (5GC)) in customer sites. A customer site can be either a physical or a virtu Core (5GC)) in customer sites. A customer site can be either a
al location. A provider is responsible for interconnecting customer sites.</t> physical or a virtual location. A provider is responsible for
interconnecting customer sites.</t>
<t>Examples of customer sites are a customer private locations
(e.g., Point of Presence (PoP) and Data Center (DC)), a Virtual Privat
e Cloud
(VPC), or servers hosted within the provider network or colocation
service.</t>
</dd> </dd>
<dt/> <dt>Resource Control:</dt>
<dd> <dd>
<t>Examples of customer sites are a customer private locations (Point <t>In the context of this document, resource control is used mainly
of Presence (PoP), Data Center (DC)), a Virtual Private Cloud (VPC), or servers to refer to buffer management and relevant Quality of Service (QoS)
hosted within the provider network or colocation service.</t> functions.</t>
</dd> </dd>
<dt>Resource Control:</dt> <dt>"5G Network Slicing" and "5G Network Slice":</dt>
<dd>Refer to "Network Slicing" and "Network Slice" as defined in <xref ta
rget="TS-28.530"/>.</dd>
</dl>
</section>
<section anchor="ext-abbr">
<name>Abbreviations</name>
<dl>
<dt>3GPP:</dt>
<dd> <dd>
<t>In the context of this document, resource control is used mainly to <t>3rd Generation Partnership Project</t>
refer to buffer management and relevant Quality of Service (QoS) functions.</t> </dd>
<dt>5GC:</dt>
<dd>
<t>5G Core</t>
</dd>
<dt>5QI:</dt>
<dd>
<t>5G QoS Indicator</t>
</dd>
<dt>A2A:</dt>
<dd>
<t>Any-to-Any</t>
</dd>
<dt>AC:</dt>
<dd>
<t>Attachment Circuit</t>
</dd>
<dt>CE:</dt>
<dd>
<t>Customer Edge</t>
</dd>
<dt>CIR:</dt>
<dd>
<t>Committed Information Rate</t>
</dd>
<dt>CS:</dt>
<dd>
<t>Customer Site</t>
</dd>
<dt>CN:</dt>
<dd>
<t>Core Network</t>
</dd>
<dt>CoS:</dt>
<dd>
<t>Class of Service</t>
</dd>
<dt>CP:</dt>
<dd>
<t>Control Plane</t>
</dd>
<dt>CU:</dt>
<dd>
<t>Centralized Unit</t>
</dd>
<dt>CU-CP:</dt>
<dd>
<t>Centralized Unit Control Plane</t>
</dd>
<dt>CU-UP:</dt>
<dd>
<t>Centralized Unit User Plane</t>
</dd>
<dt>DC:</dt>
<dd>
<t>Data Center</t>
</dd>
<dt>DDoS:</dt>
<dd>
<t>Distributed Denial of Service</t>
</dd>
<dt>DSCP:</dt>
<dd>
<t>Differentiated Services Code Point</t>
</dd>
<dt>eCPRI:</dt>
<dd>
<t>enhanced Common Public Radio Interface</t>
</dd>
<dt>FIB:</dt>
<dd>
<t>Forwarding Information Base</t>
</dd>
<dt>GPRS:</dt>
<dd>
<t>General Packet Radio Service</t>
</dd>
<dt>gNB:</dt>
<dd>
<t>gNodeB</t>
</dd>
<dt>GTP:</dt>
<dd>
<t>GPRS Tunneling Protocol</t>
</dd>
<dt>GTP-U:</dt>
<dd>
<t>GPRS Tunneling Protocol User Plane</t>
</dd>
<dt>IGP:</dt>
<dd>
<t>Interior Gateway Protocol</t>
</dd>
<dt>L2VPN:</dt>
<dd>
<t>Layer 2 Virtual Private Network</t>
</dd>
<dt>L3VPN:</dt>
<dd>
<t>Layer 3 Virtual Private Network</t>
</dd>
<dt>LSP:</dt>
<dd>
<t>Label Switched Path</t>
</dd>
<dt>MACsec</dt>
<dd>Media Access Control Security (MACsec)</dd>
<dt>MIoT:</dt>
<dd>
<t>Massive Internet of Things</t>
</dd>
<dt>MNO</dt>
<dd>Mobile Network Operator</dd>
<dt>MPLS:</dt>
<dd>
<t>Multiprotocol Label Switching</t>
</dd>
<dt>NF:</dt>
<dd>
<t>Network Function</t>
</dd>
<dt>NS:</dt>
<dd>
<t>Network Slice</t>
</dd>
<dt>NRP:</dt>
<dd>
<t>Network Resource Partition</t>
</dd>
<dt>NSC:</dt>
<dd>
<t>Network Slice Controller</t>
</dd>
<dt>PE:</dt>
<dd>
<t>Provider Edge</t>
</dd>
<dt>PIR:</dt>
<dd>
<t>Peak Information Rate</t>
</dd>
<dt>QoS:</dt>
<dd>
<t>Quality of Service</t>
</dd>
<dt>RAN:</dt>
<dd>
<t>Radio Access Network</t>
</dd>
<dt>RIB:</dt>
<dd>
<t>Routing Information Base</t>
</dd>
<dt>RSVP:</dt>
<dd>
<t>Resource Reservation Protocol</t>
</dd>
<dt>SD:</dt>
<dd>
<t>Slice Differentiator</t>
</dd>
<dt>SDP:</dt>
<dd>
<t>Service Demarcation Point</t>
</dd>
<dt>SLA:</dt>
<dd>
<t>Service Level Agreement</t>
</dd>
<dt>SLO:</dt>
<dd>
<t>Service Level Objective</t>
</dd>
<dt>S-NSSAI:</dt>
<dd>
<t>Single Network Slice Selection Assistance Information</t>
</dd>
<dt>SST:</dt>
<dd>
<t>Slice/Service Type</t>
</dd>
<dt>SR:</dt>
<dd>
<t>Segment Routing</t>
</dd>
<dt>SRv6:</dt>
<dd>
<t>Segment Routing version 6</t>
</dd>
<dt>TC:</dt>
<dd>
<t>Traffic Class</t>
</dd>
<dt>TE:</dt>
<dd>
<t>Traffic Engineering</t>
</dd>
<dt>TN:</dt>
<dd>
<t>Transport Network</t>
</dd>
<dt>UP:</dt>
<dd>
<t>User Plane</t>
</dd>
<dt>UPF:</dt>
<dd>
<t>User Plane Function</t>
</dd>
<dt>URLLC:</dt>
<dd>
<t>Ultra-Reliable Low-Latency Communication</t>
</dd>
<dt>VLAN:</dt>
<dd>
<t>Virtual Local Area Network</t>
</dd>
<dt>VPN:</dt>
<dd>
<t>Virtual Private Network</t>
</dd>
<dt>VRF:</dt>
<dd>
<t>Virtual Routing and Forwarding</t>
</dd>
<dt>VXLAN:</dt>
<dd>
<t>Virtual Extensible Local Area Network</t>
</dd> </dd>
</dl> </dl>
<t>"5G Network Slicing" (or "5G Network Slice") refers to "Network Slicing
" (or "Network Slice") as defined in the 3GPP <xref target="TS-28.530"/>.</t>
<t>An extended list of abbreviations used in this document is provided in
<xref target="ext-abbr"/>.</t>
</section> </section>
</section>
<section anchor="sec-5g"> <section anchor="sec-5g">
<name>5G Network Slicing Integration in Transport Networks</name> <name>5G Network Slicing Integration in Transport Networks</name>
<section anchor="sec-scope"> <section anchor="sec-scope">
<name>Scope of the Transport Network</name> <name>Scope of the Transport Network</name>
<t>The main 5G network building blocks are: the Radio Access Network (RA N), Core Network (CN), and Transport Network (TN). The Transport Network is defi ned by the 3GPP as (Section 1 of <xref target="TS-28.530"/>):</t> <t>The main 5G network building blocks are the Radio Access Network (RAN ), Core Network (CN), and Transport Network (TN). The Transport Network is defin ed by the 3GPP in Section 1 of <xref target="TS-28.530"/>:</t>
<blockquote> <blockquote>
<t>part supporting connectivity within and between CN and RAN parts.</ t> <t>part supporting connectivity within and between CN and RAN parts.</ t>
</blockquote> </blockquote>
<t>As discussed in Section 4.4.1 of <xref target="TS-28.530"/>, the 3GPP management system does not directly control the Transport Network: it is consid ered as a non-3GPP managed system.</t> <t>The 3GPP management system does not directly control the Transport Ne twork; it is considered a non-3GPP managed system. This is discussed in Section 4.4.1 of <xref target="TS-28.530"/>:</t>
<blockquote> <blockquote>
<t>The non-3GPP part includes TN parts. The 3GPP management system pro vides the network slice requirements to the corresponding management systems of those non-3GPP parts, e.g. the TN part supports connectivity within and between CN and AN parts.</t> <t>The non-3GPP part includes TN parts. The 3GPP management system pro vides the network slice requirements to the corresponding management systems of those non-3GPP parts, e.g. the TN part supports connectivity within and between CN and AN parts.</t>
</blockquote> </blockquote>
<t>In practice, the TN may not map to a monolithic architecture and mana gement domain. It is frequently segmented, non-uniform, and managed by different entities. For example, <xref target="fig-1"/> depicts an NF instance that is de ployed in an edge data center (DC) connected to an NF located in a Public Cloud via a WAN (e.g., MPLS-VPN service). In this example, the TN can be seen as an ab straction representing an end-to-end connectivity based upon three distinct doma ins: DC, WAN, and Public Cloud. A model for the Transport Network based on orche stration domains is introduced in <xref target="sec-orch"/>.</t> <t>In practice, the TN may not map to a monolithic architecture and mana gement domain. It is frequently segmented, non-uniform, and managed by different entities. For example, <xref target="fig-1"/> depicts an NF instance that is de ployed in an edge data center (DC) connected to an NF located in a Public Cloud via a WAN (e.g., MPLS-VPN service). In this example, the TN can be seen as an ab straction representing an end-to-end connectivity based upon three distinct doma ins: DC, WAN, and Public Cloud. A model for the Transport Network based on orche stration domains is introduced in <xref target="sec-orch"/>.</t>
<figure anchor="fig-1"> <figure anchor="fig-1">
<name>An Example of Transport Network Decomposition</name> <name>Example of Transport Network Decomposition</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="368" width="400" viewBox="0 0 400 368" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="368" width="400" viewBox="0 0 400 368" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,112 L 8,144" fill="none" stroke="black"/> <path d="M 8,112 L 8,144" fill="none" stroke="black"/>
<path d="M 8,192 L 8,352" fill="none" stroke="black"/> <path d="M 8,192 L 8,352" fill="none" stroke="black"/>
<path d="M 16,48 L 16,104" fill="none" stroke="black"/> <path d="M 16,48 L 16,104" fill="none" stroke="black"/>
<path d="M 24,224 L 24,240" fill="none" stroke="black"/> <path d="M 24,224 L 24,240" fill="none" stroke="black"/>
<path d="M 32,112 L 32,144" fill="none" stroke="black"/> <path d="M 32,112 L 32,144" fill="none" stroke="black"/>
<path d="M 56,32 L 56,64" fill="none" stroke="black"/> <path d="M 56,32 L 56,64" fill="none" stroke="black"/>
<path d="M 56,112 L 56,144" fill="none" stroke="black"/> <path d="M 56,112 L 56,144" fill="none" stroke="black"/>
<path d="M 64,224 L 64,240" fill="none" stroke="black"/> <path d="M 64,224 L 64,240" fill="none" stroke="black"/>
skipping to change at line 399 skipping to change at line 716
| | +--+ +--+ | | | | +--+ +--+ | |
| | |PE| |PE| | | | | |PE| |PE| | |
| | +--+ +--+ | | | | +--+ +--+ | |
| | | | | | | | | | | |
+-----------------+ +----------+ +--------+ +-----------------+ +----------+ +--------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-5gtn"> <section anchor="sec-5gtn">
<name>5G Network Slicing versus Transport Network Slicing</name> <name>5G Network Slicing Versus Transport Network Slicing</name>
<t>Network slicing has a different meaning in the 3GPP mobile world and transport world. <t>Network slicing has a different meaning in the 3GPP mobile world and transport world.
This difference can be seen from the descriptions below that set out This difference can be seen from the descriptions below that set out
the objectives of 5G Network Slicing (<xref target="sec-5g-slicing"/>) and Trans port Network the objectives of 5G Network Slicing (<xref target="sec-5g-slicing"/>) and Trans port Network
Slicing (<xref target="sec-tn-slicing"/>). These descriptions are not intended t o be exhaustive.</t> Slicing (<xref target="sec-tn-slicing"/>). These descriptions are not intended t o be exhaustive.</t>
<section anchor="sec-5g-slicing"> <section anchor="sec-5g-slicing">
<name>5G Network Slicing</name> <name>5G Network Slicing</name>
<t>5G Network Slicing is defined by the 3GPP <xref target="TS-28.530" /> as an approach:</t> <t>In <xref target="TS-28.530"/>, the 3GPP defines 5G Network Slicing as an approach:</t>
<blockquote> <blockquote>
<t>where logical networks/partitions are created, with appropriate i solation, resources and optimized topology to serve a purpose or service categor y (e.g. use case/traffic category, or for MNO internal reasons) or customers (lo gical system created "on demand").</t> <t>where logical networks/partitions are created, with appropriate i solation, resources and optimized topology to serve a purpose or service categor y (e.g. use case/traffic category, or for MNO internal reasons) or customers (lo gical system created "on demand").</t>
</blockquote> </blockquote>
<t>These resources are from the TN, RAN, CN domains, and the underlyin g infrastructure.</t> <t>These resources are from the TN, RAN, CN domains, and the underlyin g infrastructure.</t>
<t>Section 3.1 of <xref target="TS-28.530"/> defines 5G Network Slice as:</t> <t>Section 3.1 of <xref target="TS-28.530"/> defines a 5G Network Slic e as:</t>
<blockquote> <blockquote>
<t>a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slic e customers.</t> <t>a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slic e customers.</t>
</blockquote> </blockquote>
</section> </section>
<section anchor="sec-tn-slicing"> <section anchor="sec-tn-slicing">
<name>Transport Network Slicing</name> <name>Transport Network Slicing</name>
<t>The term "TN slice" refers to a slice in the Transport Network doma in of the 5G architecture. The following further elaborates on how Transport Net work Slicing is <t>The term "TN slice" refers to a slice in the Transport Network doma in of the 5G architecture. This section elaborates on how Transport Network Slic ing is
defined in the context of this document. It draws on the 3GPP definitions defined in the context of this document. It draws on the 3GPP definitions
of Transport Network and Network Slicing as described in <xref target="TS-28.530 "/>.</t> of "Transport Network" and "Network Slicing" in <xref target="TS-28.530"/>.</t>
<t>The objective of Transport Network Slicing is to isolate, <t>The objective of Transport Network Slicing is to isolate,
guarantee, or prioritize Transport Network resources for Slice Services. Example s of such resources are: guarantee, or prioritize Transport Network resources for Slice Services. Example s of such resources include
buffers, link capacity, or even Routing Information Base (RIB) and Forwarding In formation Base (FIB).</t> buffers, link capacity, or even Routing Information Base (RIB) and Forwarding In formation Base (FIB).</t>
<t>Transport Network Slicing provides various degrees of sharing of re sources between slices (<xref section="8" sectionFormat="of" target="RFC9543"/>) . For example, the network capacity can be shared by all slices, usually with a guaranteed minimum per slice, or each individual slice can be allocated dedicate d network capacity. Parts of a given network may use the former, while others us e the latter. For example, in order to satisfy local engineering guidelines and specific service requirements, shared TN resources could be provided in the back haul (or midhaul), and dedicated TN resources could be provided in the midhaul ( or backhaul). The capacity partitioning strategy is deployment specific.</t> <t>Transport Network Slicing provides various degrees of sharing of re sources between slices (<xref section="8" sectionFormat="of" target="RFC9543"/>) . For example, the network capacity can be shared by all slices, usually with a guaranteed minimum per slice, or each individual slice can be allocated dedicate d network capacity. Parts of a given network may use the former, while others us e the latter. For example, in order to satisfy local engineering guidelines and specific service requirements, shared TN resources could be provided in the back haul (or midhaul), and dedicated TN resources could be provided in the midhaul ( or backhaul). The capacity partitioning strategy is deployment specific.</t>
<t>There are different components to implement TN slices based upon <t>There are different components to implement TN slices based upon
mechanisms such as Virtual Routing and Forwarding instances (VRFs) mechanisms such as Virtual Routing and Forwarding (VRF) instances
for logical separation, QoS, and Traffic for logical separation, QoS, and Traffic
Engineering (TE). Whether all or a subset of these components are enabled is a d eployment choice.</t> Engineering (TE). Whether all or a subset of these components are enabled is a d eployment choice.</t>
</section> </section>
</section> </section>
<section anchor="sec-ref-design"> <section anchor="sec-ref-design">
<name>Transport Network Reference Design</name> <name>Transport Network Reference Design</name>
<t><xref target="fig-tn-arch"/> depicts the reference design used in thi <t><xref target="fig-tn-arch"/> depicts the reference design used in thi
s document for modeling the Transport Network based on management perimeters (Cu s document for modeling the Transport Network based on management perimeters (cu
stomer vs. Provider).</t> stomer vs. provider).</t>
<figure anchor="fig-tn-arch"> <figure anchor="fig-tn-arch">
<name>Reference Design with Customer Site and Provider Network</name> <name>Reference Design with Customer Site and Provider Network</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="288" width="600" viewBox="0 0 600 288" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="288" width="600" viewBox="0 0 600 288" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,96 L 8,240" fill="none" stroke="black"/> <path d="M 8,96 L 8,240" fill="none" stroke="black"/>
<path d="M 24,160 L 24,192" fill="none" stroke="black"/> <path d="M 24,160 L 24,192" fill="none" stroke="black"/>
<path d="M 48,160 L 48,192" fill="none" stroke="black"/> <path d="M 48,160 L 48,192" fill="none" stroke="black"/>
<path d="M 88,144 L 88,208" fill="none" stroke="black"/> <path d="M 88,144 L 88,208" fill="none" stroke="black"/>
<path d="M 128,144 L 128,208" fill="none" stroke="black"/> <path d="M 128,144 L 128,208" fill="none" stroke="black"/>
<path d="M 144,96 L 144,168" fill="none" stroke="black"/> <path d="M 144,96 L 144,168" fill="none" stroke="black"/>
skipping to change at line 536 skipping to change at line 854
+----------------+ +---------------------+ +----------------+ +----------------+ +---------------------+ +----------------+
<-----------------Transport Network---------------> <-----------------Transport Network--------------->
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The description of the main components shown in <xref target="fig-tn- arch"/> is provided in the following subsections.</t> <t>The description of the main components shown in <xref target="fig-tn- arch"/> is provided in the following subsections.</t>
<section anchor="sec-cs"> <section anchor="sec-cs">
<name>Customer Site (CS)</name> <name>Customer Site (CS)</name>
<t>On top of 5G NFs, a customer may manage additional TN elements (e.g ., servers, routers, and switches) within a customer site.</t> <t>On top of 5G NFs, a customer may manage additional TN elements (e.g ., servers, routers, and switches) within a customer site.</t>
<t>NFs may be hosted on a CE, directly connected to a CE, or be locate <t>NFs may be hosted on a CE, directly connected to a CE, or located m
d multiple IP hops from a CE.</t> ultiple IP hops from a CE.</t>
<t>In some contexts, the connectivity between NFs that belong to the s <t>In some contexts, the connectivity between NFs that belong to the s
ame site can be via achieved the provider network.</t> ame site can be achieved via the provider network.</t>
<t>The orchestration of the TN within a customer site involves a set o <t>The orchestration of the TN within a customer site involves a set o
f controllers for automation purposes (e.g., Network Functions Virtualization In f controllers for automation purposes (e.g., Network Function Virtualization Inf
frastructure (NFVI), Container Network Interface (CNI), Fabric Managers, or Publ rastructure (NFVI), Container Network Interface (CNI), Fabric Managers, or Publi
ic Cloud APIs). It is out of scope to document how these controllers are impleme c Cloud APIs). Documenting how these controllers are implemented is out of scop
nted.</t> e for this document.</t>
</section> </section>
<section anchor="sec-ce"> <section anchor="sec-ce">
<name>Customer Edge (CE)</name> <name>Customer Edge (CE)</name>
<t>A CE is a function that provides logical connectivity of a customer site (<xref target="sec-cs"/>) to the provider network (<xref target="sec-pn"/> ). The logical connectivity is enforced at Layer 2 and/or Layer 3 and is denomin ated an Attachment Circuit (AC) (<xref target="sec-ac"/>). Examples of CEs inclu de TN components (e.g., router, switch, and firewalls) and also 5G NFs (i.e., an element of the 5G domain such as Centralized Unit (CU), Distributed Unit (DU), or User Plane Function (UPF)).</t> <t>A CE is a function that provides logical connectivity of a customer site (<xref target="sec-cs"/>) to the provider network (<xref target="sec-pn"/> ). The logical connectivity is enforced at Layer 2 and/or Layer 3 and is denomin ated an Attachment Circuit (AC) (<xref target="sec-ac"/>). Examples of CEs inclu de TN components (e.g., router, switch, and firewalls) and also 5G NFs (i.e., an element of the 5G domain such as Centralized Unit (CU), Distributed Unit (DU), or User Plane Function (UPF)).</t>
<t>A CE is typically managed by the customer, but it can also be co-ma <t>A CE is typically managed by the customer, but it can also be co-ma
naged with the provider. A co-managed CE is orchestrated by both the customer an naged with the provider. A co-managed CE is orchestrated by both the customer an
d the provider. In this case, the customer and provider usually have control on d the provider. In this case, the customer and provider usually have control on
distinct device configuration perimeters. A co-managed CE has both PE and CE fun distinct device configuration perimeters. A co-managed CE has both PE and CE fun
ctions and there is no strict AC connection, although one may consider that the ctions, and there is no strict AC connection, although one may consider that the
AC stitching logic happens internally within the CE itself. The provider manages AC stitching logic happens internally within the CE itself. The provider manage
the AC between the CE and the PE.</t> s the AC between the CE and the PE.</t>
<t>This document generalizes the definition of a CE with the introduct
ion of "Distributed CE"; that is, the logical connectivity is realized by config <t>This document generalizes the definition of a CE with the introduct
uring multiple devices in the customer domain. The CE function is distributed. A ion of "distributed CE"; that is, the logical connectivity is realized by config
n example of distributed CE is the realization of an interconnection using a L3V uring multiple devices in the customer domain. The CE function is distributed. A
PN service based on a distributed CE composed of a switch (Layer 2) and a router n example of distributed CE is the realization of an interconnection using an L3
(Layer 3) (<xref target="fig-distribute-ce"/>). Another example of distributed VPN service based on a distributed CE composed of a switch (Layer 2) and a route
CE is shown in <xref target="fig-50"/>.</t> r (Layer 3) (<xref target="fig-distribute-ce"/>). Another example of distributed
CE is shown in <xref target="fig-50"/>.</t>
<!-- [rfced] Figure 4 contains "SW" and "RTR", which are not used elsewhere in
the document. We believe these stand for "switch" and "router", respectively.
May we update this sentence in one of the following ways to make this clear?
Original:
An example of distributed CE is the
realization of an interconnection using a L3VPN service based on a
distributed CE composed of a switch (Layer 2) and a router (Layer 3)
(Figure 4).
Perhaps:
An example of distributed CE is the
realization of an interconnection using an L3VPN service based on a
distributed CE composed of a switch (SW) in Layer 2 and a router (RTR)
in Layer 3, as shown in Figure 4.
Or:
An example of distributed CE is the
realization of an interconnection using an L3VPN service based on a
distributed CE composed of a switch (Layer 2) and a router (Layer 3);
see SW and RTR in Figure 4.
-->
<figure anchor="fig-distribute-ce"> <figure anchor="fig-distribute-ce">
<name>Example of Distributed CE</name> <name>Example of Distributed CE</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="256" width="424" viewBox="0 0 424 256" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="256" width="424" viewBox="0 0 424 256" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,32 L 8,240" fill="none" stroke="black"/> <path d="M 8,32 L 8,240" fill="none" stroke="black"/>
<path d="M 24,80 L 24,208" fill="none" stroke="black"/> <path d="M 24,80 L 24,208" fill="none" stroke="black"/>
<path d="M 40,112 L 40,176" fill="none" stroke="black"/> <path d="M 40,112 L 40,176" fill="none" stroke="black"/>
<path d="M 72,112 L 72,176" fill="none" stroke="black"/> <path d="M 72,112 L 72,176" fill="none" stroke="black"/>
<path d="M 96,112 L 96,136" fill="none" stroke="black"/> <path d="M 96,112 L 96,136" fill="none" stroke="black"/>
<path d="M 96,152 L 96,176" fill="none" stroke="black"/> <path d="M 96,152 L 96,176" fill="none" stroke="black"/>
skipping to change at line 614 skipping to change at line 957
| | | +------------AC----------+ PE | | | | | +------------AC----------+ PE | |
| | |RTR| | SW ================== | | | | |RTR| | SW ================== | |
| | +---+ +----+ | +----+ | | | +---+ +----+ | +----+ |
| | | | | | | | | |
| +--Distributed--+ | | | +--Distributed--+ | |
| CE | | | | CE | | |
+--------------+ +--------------+ +--------------+ +--------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>While in most cases CEs connect to PEs using IP (e.g., via Layer 3 VLAN subinterfaces), a CE may also connect to the provider network using other t echnologies such as MPLS -potentially over IP tunnels- or Segment Routing over I Pv6 (SRv6) <xref target="RFC8986"/>. The CE has thus awareness of provider servi ces configuration (e.g., control plane identifiers such as Route Targets (RTs) a nd Route Distinguishers (RDs)). However, the CE is still managed by the customer and the AC is based on MPLS or SRv6 data plane technologies. The complete termi nation of the AC within the provider network may happen on distinct routers: thi s is another example of distributed PE. Service-aware CEs are used, for example, in the deployments discussed in Sections <xref format="counter" target="sec-10b "/> and <xref format="counter" target="sec-10c"/>.</t> <t>In most cases, CEs connect to PEs using IP (e.g., via Layer 3 VLAN subinterfaces), but a CE may also connect to the provider network using other te chnologies such as MPLS (potentially over IP tunnels) or Segment Routing over IP v6 (SRv6) <xref target="RFC8986"/>. Thus, the CE has awareness of provider servi ce configuration (e.g., control plane identifiers such as Route Targets (RTs) an d Route Distinguishers (RDs)). However, the CE is still managed by the customer, and the AC is based on MPLS or SRv6 data plane technologies. The complete termi nation of the AC within the provider network may happen on distinct routers; thi s is another example of distributed PE. Service-aware CEs are used, for example, in the deployments discussed in Sections <xref format="counter" target="sec-10b "/> and <xref format="counter" target="sec-10c"/>.</t>
</section> </section>
<section anchor="sec-pn"> <section anchor="sec-pn">
<name>Provider Network</name> <name>Provider Network</name>
<t>A provider uses a provider network to interconnect customer sites. This document assumes that the provider network is based on IP, MPLS, or both.</ t> <t>A provider uses a provider network to interconnect customer sites. This document assumes that the provider network is based on IP, MPLS, or both.</ t>
</section> </section>
<section anchor="sec-pe"> <section anchor="sec-pe">
<name>Provider Edge (PE)</name> <name>Provider Edge (PE)</name>
<t>PE is a device managed by a provider that is connected to a CE. The <t>A PE is a device managed by a provider that is connected to a CE. T
connectivity between a CE and a PE is achieved using one or multiple ACs (<xref he connectivity between a CE and a PE is achieved using one or multiple ACs (<xr
target="sec-ac"/>).</t> ef target="sec-ac"/>).</t>
<t>This document generalizes the PE definition with the introduction o <t>This document generalizes the PE definition with the introduction o
f "Distributed PE"; that is, the logical connectivity is realized by configuring f "distributed PE"; that is, the logical connectivity is realized by configuring
multiple devices in the provider network (i.e., provider orchestration domain). multiple devices in the provider network (i.e., the provider orchestration doma
The PE function is distributed.</t> in). The PE function is distributed.</t>
<t>An example of a distributed PE is the "Managed CE service". For exa <t>An example of a distributed PE is the "managed CE service". For exa
mple, a provider delivers VPN services using CEs and PEs which are both managed mple, a provider delivers VPN services using CEs and PEs that are both managed b
by the provider (case (i) in <xref target="fig-50"/>). The managed CE can also b y the provider (example (i) in <xref target="fig-50"/>). The managed CE can also
e a Data Center Gateway as depicted in the example (ii) of <xref target="fig-50" be a Data Center Gateway as depicted in example (ii) of <xref target="fig-50"/
/>. A provider-managed CE may attach to CEs of multiple customers. However, this >. A provider-managed CE may attach to CEs of multiple customers. However, this
device is part of the provider network.</t> device is part of the provider network.</t>
<figure anchor="fig-50"> <figure anchor="fig-50">
<name>Examples of Distributed PE</name> <name>Examples of Distributed PE</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="480" width="424" viewBox="0 0 424 480" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="480" width="424" viewBox="0 0 424 480" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,32 L 8,208" fill="none" stroke="black"/> <path d="M 8,32 L 8,208" fill="none" stroke="black"/>
<path d="M 8,256 L 8,448" fill="none" stroke="black"/> <path d="M 8,256 L 8,448" fill="none" stroke="black"/>
<path d="M 32,304 L 32,400" fill="none" stroke="black"/> <path d="M 32,304 L 32,400" fill="none" stroke="black"/>
<path d="M 56,336 L 56,352" fill="none" stroke="black"/> <path d="M 56,336 L 56,352" fill="none" stroke="black"/>
<path d="M 96,96 L 96,160" fill="none" stroke="black"/> <path d="M 96,96 L 96,160" fill="none" stroke="black"/>
<path d="M 96,336 L 96,352" fill="none" stroke="black"/> <path d="M 96,336 L 96,352" fill="none" stroke="black"/>
skipping to change at line 785 skipping to change at line 1128
| | .-. .-. .-. .-. ============= | | | | | | | .-. .-. .-. .-. ============= | | | | |
| | '-' '-' '-' '-' | | +----+ +----+ | | | | '-' '-' '-' '-' | | +----+ +----+ | |
| +---Distributed---+ +---Distributed---+ | | +---Distributed---+ +---Distributed---+ |
| CE | | PE | | CE | | PE |
| | | | | | | |
+--Data Center-+ +--------------+ +--Data Center-+ +--------------+
(ii) Distributed PE and CE (ii) Distributed PE and CE
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In subsequent sections of this document, the terms CE and PE are us ed for both single and distributed devices.</t> <t>In subsequent sections of this document, the terms "CE" and "PE" ar e used for both single and distributed devices.</t>
</section> </section>
<section anchor="sec-ac"> <section anchor="sec-ac">
<name>Attachment Circuit (AC)</name> <name>Attachment Circuit (AC)</name>
<t>The AC is the logical connection that attaches a CE (<xref target=" sec-ce"/>) to a PE (<xref target="sec-pe"/>). A CE is connected to a PE via one or multiple ACs.</t> <t>The AC is the logical connection that attaches a CE (<xref target=" sec-ce"/>) to a PE (<xref target="sec-pe"/>). A CE is connected to a PE via one or multiple ACs.</t>
<t>This document uses the concept of distributed CE and PE (Sections < <t>This document uses the concept of distributed CE and PE (Sections <
xref format="counter" target="sec-ce"/> and <xref format="counter" target="sec-p xref format="counter" target="sec-ce"/> and <xref format="counter" target="sec-p
e"/>) to consolidate a CE/AC/PE definition that is consistent with the orchestra e"/>) to consolidate a CE/AC/PE definition that is consistent with the orchestra
tion perimeters (<xref target="sec-orch"/>). The CEs and PEs delimit respectivel tion perimeters (<xref target="sec-orch"/>). The CEs and PEs delimit the custome
y the customer and provider orchestration domains, while an AC interconnects the r and provider orchestration domains, respectively, while an AC interconnects th
se domains.</t> ese domains.</t>
<t>For consistency with the AC data models terminology (e.g., <xref ta
rget="I-D.ietf-opsawg-teas-attachment-circuit"/> and <xref target="I-D.ietf-opsa <t>For consistency with the terminology used in AC data models (e.g.,
wg-ntw-attachment-circuit"/>), this document assumes that an AC is configured on the data models defined in <xref target="RFC9834"/> and <xref target="RFC9835"/>
a "bearer", which represents the underlying connectivity. For example, the bear ), this document assumes that an AC is configured on a "bearer", which represent
er is illustrated with "===" in Figures <xref format="counter" target="fig-distr s the underlying connectivity. For example, the bearer is illustrated with "==="
ibute-ce"/> and <xref format="counter" target="fig-50"/>.</t> in Figures <xref format="counter" target="fig-distribute-ce"/> and <xref format
<t>An AC is technology-specific. Examples of ACs are Virtual Local Are ="counter" target="fig-50"/>.</t>
a Networks (VLANs) (AC) configured on a physical interface (bearer) or an Overla
y VXLAN EVI (AC) configured on an IP underlay (bearer).</t> <!-- [rfced] Are the two instances of "(AC)" needed here?
<t>Deployment cases where the AC is also managed by the provider are n
ot discussed in the document because the setup of such an AC does not require an Original:
y coordination between the customer and provider orchestration domains.</t> Examples of ACs are Virtual Local Area
Networks (VLANs) (AC) configured on a physical interface (bearer) or
an Overlay VXLAN EVI (AC) configured on an IP underlay (bearer).
Perhaps:
Examples of ACs are Virtual Local Area
Networks (VLANs) configured on a physical interface (bearer) or
an Overlay VXLAN EVI configured on an IP underlay (bearer).
-->
<t>An AC is technology specific. Examples of ACs are Virtual Local Are
a Networks (VLANs) (AC) configured on a physical interface (bearer) or an Overla
y VXLAN EVI (AC) configured on an IP underlay (bearer).</t>
<t>Deployment cases where the AC is also managed by the provider are n
ot discussed in this document because the setup of such an AC does not require a
ny coordination between the customer and provider orchestration domains.</t>
<aside> <aside>
<t>In order to keep the figures simple, only one AC and single-homed CEs are represented. Also, the underlying bearers are not represented in most o f the figures. <t>Note: In order to keep the figures simple, only one AC and single -homed CEs are represented. Also, the underlying bearers are not represented in most of the figures.
However, this document does not exclude the instantiation of multiple ACs betwee n a CE and a PE nor the presence of CEs that are attached to more than one PE.</ t> However, this document does not exclude the instantiation of multiple ACs betwee n a CE and a PE nor the presence of CEs that are attached to more than one PE.</ t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="sec-orch"> <section anchor="sec-orch">
<name>Orchestration Overview</name> <name>Orchestration Overview</name>
<section anchor="sec-5g-sli-arch"> <section anchor="sec-5g-sli-arch">
<name>5G End-to-End Slice Orchestration Architecture</name> <name>5G End-to-End Slice Orchestration Architecture</name>
<t>This section introduces a global framework for the orchestration of a 5G end-to-end slice (a.k.a. 5G Network Slice) with a zoom on TN parts. This f ramework helps to delimit the realization scope of RFC 9543 Network Slices and i dentify interactions that are required for the realization of such slices.</t> <t>This section introduces a global framework for the orchestration of a 5G end-to-end slice (a.k.a. 5G Network Slice) with a zoom on TN parts. This f ramework helps to delimit the realization scope of RFC&nbsp;9543 Network Slices and identify interactions that are required for the realization of such slices.< /t>
<t>This framework is consistent with the management coordination examp le shown in Figure 4.7.1 of <xref target="TS-28.530"/>.</t> <t>This framework is consistent with the management coordination examp le shown in Figure 4.7.1 of <xref target="TS-28.530"/>.</t>
<t>In reference to <xref target="_figure-orch"/>, a 5G End-to-End Netw
ork Slice Orchestrator (5G NSO) is responsible for orchestrating 5G Network Slic <!-- [rfced] Is "End-to-End" intended to be part of the expansion for "5G NSO"?
es end-to-end. The details of the 5G NSO are out of the scope of this document.
The realization of the 5G Network Slices spans RAN, CN, and TN. As mentioned in Original:
<xref target="sec-scope"/>, the RAN and CN are under the responsibility of the 3 In reference to Figure 6, a 5G End-to-End Network Slice Orchestrator
GPP Management System, while the TN is not. The orchestration of the TN is split (5G NSO) is responsible for orchestrating 5G Network Slices end-to-
into two subdomains in conformance with the reference design in <xref target="s end.
ec-ref-design"/>:</t>
Perhaps:
In Figure 6, a 5G Network Slice Orchestrator
(5G NSO) is responsible for orchestrating 5G Network Slices end-to-
end.
-->
<t>In <xref target="_figure-orch"/>, a 5G End-to-End Network Slice Orchestrator
(5G NSO) is responsible for orchestrating 5G Network Slices end-to-end. The deta
ils of the 5G NSO are out of the scope of this document. The realization of the
5G Network Slices spans RAN, CN, and TN. As mentioned in <xref target="sec-scope
"/>, the RAN and CN are under the responsibility of the 3GPP management system,
while the TN is not. The orchestration of the TN is split into two subdomains in
conformance with the reference design in <xref target="sec-ref-design"/>:</t>
<dl> <dl>
<dt>Provider Network Orchestration domain:</dt> <dt>Provider Network Orchestration domain:</dt>
<dd> <dd>
<t>As defined in <xref target="RFC9543"/>, the provider relies on a Network Slice Controller (NSC) to manage and orchestrate RFC 9543 Network Slic es in the provider network. This framework allows for managing connectivity with SLOs.</t> <t>As defined in <xref target="RFC9543"/>, the provider relies on a Network Slice Controller (NSC) to manage and orchestrate RFC 9543 Network Slic es in the provider network. This framework allows for managing connectivity with SLOs.</t>
</dd> </dd>
<dt>Customer Site Orchestration domain:</dt> <dt>Customer Site Orchestration domain:</dt>
<dd> <dd>
<t>The Orchestration of TN elements of the customer sites relies u pon a variety of controllers (e.g., Fabric Manager, Element Management System, or Virtualized Infrastructure Manager (VIM)).</t> <t>The orchestration of TN elements of the customer sites relies u pon a variety of controllers (e.g., Fabric Manager, Element Management System, or Virtualized Infrastructure Manager (VIM)).</t>
</dd> </dd>
</dl> </dl>
<t>A TN slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in <xref target="sec-tn-nsi" />.</t> <t>A TN slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in <xref target="sec-tn-nsi" />.</t>
<t>A TN slice might be considered as a variant of horizontal compositi on of Network Slices mentioned in Appendix A.6 of <xref target="RFC9543"/>.</t> <t>A TN slice might be considered as a variant of horizontal compositi on of Network Slices mentioned in <xref section="A.6" target="RFC9543"/>.</t>
<figure anchor="_figure-orch"> <figure anchor="_figure-orch">
<name>5G End-to-End Slice Orchestration with TN</name> <name>5G End-to-End Slice Orchestration with TN</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="592" width="544" viewBox="0 0 544 592" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="592" width="544" viewBox="0 0 544 592" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,368 L 8,512" fill="none" stroke="black"/> <path d="M 8,368 L 8,512" fill="none" stroke="black"/>
<path d="M 24,416 L 24,448" fill="none" stroke="black"/> <path d="M 24,416 L 24,448" fill="none" stroke="black"/>
<path d="M 32,144 L 32,408" fill="none" stroke="black"/> <path d="M 32,144 L 32,408" fill="none" stroke="black"/>
<path d="M 48,416 L 48,448" fill="none" stroke="black"/> <path d="M 48,416 L 48,448" fill="none" stroke="black"/>
<path d="M 56,224 L 56,288" fill="none" stroke="black"/> <path d="M 56,224 L 56,288" fill="none" stroke="black"/>
<path d="M 72,240 L 72,288" fill="none" stroke="black"/> <path d="M 72,240 L 72,288" fill="none" stroke="black"/>
skipping to change at line 1008 skipping to change at line 1380
| Customer | | | | Customer | | Customer | | | | Customer |
| Site | | | | Site | | Site | | | | Site |
+-------------+ +-----------------+ +----------+ +-------------+ +-----------------+ +----------+
RFC 9543 RFC 9543
|-----Network Slice---| |-----Network Slice---|
|--------------------TN Slice-------------------| |--------------------TN Slice-------------------|
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The various orchestration depicted in <xref target="_figure-orch"/>
encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned <!-- [rfced] Should "various orchestration" in this sentence be updated to
, e.g., in Figure 5 of <xref target="I-D.ietf-teas-5g-network-slice-application" either "various orchestration domains" or "various orchestrations"? Also,
/>.</t> is "e.g." needed in the sentence?
Original:
The various orchestration depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned, e.g., in
Figure 5 of [I-D.ietf-teas-5g-network-slice-application].
Perhaps:
The various orchestration domains depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned in
Figure 5 of [NS-APP].
Or:
The various orchestrations depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned in
Figure 5 of [NS-APP].
-->
<t>The various orchestration depicted in <xref target="_figure-orch"/>
encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned,
e.g., in Figure 5 of <xref target="I-D.ietf-teas-5g-network-slice-application"/
>.</t>
</section> </section>
<section anchor="sec-tn-nsi"> <section anchor="sec-tn-nsi">
<name>Transport Network Segments and Network Slice Instantiation</name > <name>Transport Network Segments and Network Slice Instantiation</name >
<t>The concept of distributed PE (<xref target="sec-pe"/>) assimilates <t>The concept of distributed PE (<xref target="sec-pe"/>) assimilates
CE-based SDPs defined in <xref section="5.2" sectionFormat="of" target="RFC9543 the CE-based SDPs defined in <xref section="5.2" sectionFormat="of" target="RFC
"/> (i.e., Types 1 and 2) as SDP Type 3 or 4 in this document.</t> 9543"/> (i.e., Types 1 and 2) as SDP Types 3 or 4 in this document.</t>
<t>In reference to the architecture depicted in <xref target="sec-5g-s <t>In the architecture depicted in <xref target="sec-5g-sli-arch"/>, t
li-arch"/>, the connectivity between NFs can be decomposed into three main segme he connectivity between NFs can be decomposed into three main segment types:</t>
nt types:</t>
<dl> <dl>
<dt>Customer Site:</dt> <dt>Customer Site:</dt>
<dd> <dd>
<t>Either connects NFs located in the same customer site or connec ts an NF to a CE.</t> <t>Either connects NFs located in the same customer site or connec ts an NF to a CE.</t>
</dd> <t>This segment may not be present if the NF is the CE. In this ca
<dt/> se, the AC connects the NF to a PE.</t>
<dd> <t>The realization of this segment is driven by the 5G Network Orc
<t>This segment may not be present if the NF is the CE. In this ca hestration (e.g., NF instantiation) and the Customer Site Orchestration for the
se the AC connects the NF to a PE.</t> TN part.</t>
</dd>
<dt/>
<dd>
<t>The realization of this segment is driven by the 5G Network Orc
hestration (e.g., NFs instantiation) and the Customer Site Orchestration for the
TN part.</t>
</dd> </dd>
<dt>Provider Network:</dt> <dt>Provider Network:</dt>
<dd> <dd>
<t>Represents the connectivity between two PEs. The realization of this segment is controlled by an NSC (<xref section="6.3" sectionFormat="of" ta rget="RFC9543"/>).</t> <t>Represents the connectivity between two PEs. The realization of this segment is controlled by an NSC (<xref section="6.3" sectionFormat="of" ta rget="RFC9543"/>).</t>
</dd> </dd>
<dt>Attachment Circuit:</dt> <dt>Attachment Circuit:</dt>
<dd> <dd>
<t>The orchestration of this segment relies partially upon an NSC for the configuration of the AC on the PE customer-facing interfaces and the Cus tomer Site Orchestration for the configuration of the AC on the CE.</t> <t>The orchestration of this segment relies partially upon an NSC for the configuration of the AC on the PE customer-facing interfaces and the Cus tomer Site Orchestration for the configuration of the AC on the CE.</t>
</dd>
<dt/>
<dd>
<t>PEs and CEs that are connected via an AC need to be <t>PEs and CEs that are connected via an AC need to be
provisioned with consistent data plane and control plane information (VLAN- provisioned with consistent data plane and control plane information (VLAN IDs,
IDs, IP addresses/subnets, BGP Autonomous System (AS) Number, etc.). Hence, the IP addresses/subnets, BGP Autonomous System Number (ASN), etc.). Hence, the rea
realization of this lization of this
interconnection is technology-specific and requires coordination between the Cus interconnection is technology specific and requires coordination between the Cus
tomer Site Orchestration and an NSC. Automating the provisioning and management tomer Site Orchestration and an NSC. Automating the provisioning and management
of the AC is thus key to automate the overall service provisioning. Aligned with of the AC is thus key to automate the overall service provisioning. Aligned with
<xref target="RFC8969"/>, this document assumes that this coordination is based <xref target="RFC8969"/>, this document assumes that this coordination is based
upon standard YANG data models and APIs.</t> upon standard YANG data models and APIs.</t>
</dd> <t>The provisioning of an RFC 9543 Network Slice may rely on new o
<dt/> r existing ACs.</t>
<dd>
<t>The provisioning of a RFC9543 Network Slice may rely on new or
existing ACs.</t>
</dd>
<dt/>
<dd>
<t><xref target="_figure-4"/> is a basic example of a Layer 3 CE-P E link realization <t><xref target="_figure-4"/> is a basic example of a Layer 3 CE-P E link realization
with shared network resources (such as VLAN-IDs and IP prefixes) which with shared network resources (such as VLAN IDs and IP prefixes), which
are passed between Orchestrators via a dedicated interface, e.g., the Network Sl are passed between orchestrators via a dedicated interface, e.g., the Network Sl
ice Service Model (NSSM) <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang ice Service Model (NSSM) <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang
"/> or the Attachment Circuit-as-a-Service (ACaaS) <xref target="I-D.ietf-opsawg "/> or Attachment Circuits as a Service (ACaaS) <xref target="RFC9834"/>.</t>
-teas-attachment-circuit"/>.</t>
</dd> </dd>
</dl> </dl>
<figure anchor="_figure-4"> <figure anchor="_figure-4">
<name>Coordination of Transport Network Resources for the AC Provisi oning</name> <name>Coordination of Transport Network Resources for AC Provisionin g</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="320" width="472" viewBox="0 0 472 320" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="320" width="472" viewBox="0 0 472 320" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,160 L 8,272" fill="none" stroke="black"/> <path d="M 8,160 L 8,272" fill="none" stroke="black"/>
<path d="M 24,48 L 24,96" fill="none" stroke="black"/> <path d="M 24,48 L 24,96" fill="none" stroke="black"/>
<path d="M 24,192 L 24,224" fill="none" stroke="black"/> <path d="M 24,192 L 24,224" fill="none" stroke="black"/>
<path d="M 48,192 L 48,224" fill="none" stroke="black"/> <path d="M 48,192 L 48,224" fill="none" stroke="black"/>
<path d="M 96,192 L 96,224" fill="none" stroke="black"/> <path d="M 96,192 L 96,224" fill="none" stroke="black"/>
<path d="M 120,192 L 120,224" fill="none" stroke="black"/> <path d="M 120,192 L 120,224" fill="none" stroke="black"/>
<path d="M 136,120 L 136,184" fill="none" stroke="black"/> <path d="M 136,120 L 136,184" fill="none" stroke="black"/>
<path d="M 152,48 L 152,96" fill="none" stroke="black"/> <path d="M 152,48 L 152,96" fill="none" stroke="black"/>
skipping to change at line 1106 skipping to change at line 1483
<path d="M 448,32 C 456.83064,32 464,39.16936 464,48" fill="no ne" stroke="black"/> <path d="M 448,32 C 456.83064,32 464,39.16936 464,48" fill="no ne" stroke="black"/>
<path d="M 40,112 C 31.16936,112 24,104.83064 24,96" fill="non e" stroke="black"/> <path d="M 40,112 C 31.16936,112 24,104.83064 24,96" fill="non e" stroke="black"/>
<path d="M 136,112 C 144.83064,112 152,104.83064 152,96" fill= "none" stroke="black"/> <path d="M 136,112 C 144.83064,112 152,104.83064 152,96" fill= "none" stroke="black"/>
<path d="M 328,112 C 319.16936,112 312,104.83064 312,96" fill= "none" stroke="black"/> <path d="M 328,112 C 319.16936,112 312,104.83064 312,96" fill= "none" stroke="black"/>
<path d="M 448,112 C 456.83064,112 464,104.83064 464,96" fill= "none" stroke="black"/> <path d="M 448,112 C 456.83064,112 464,104.83064 464,96" fill= "none" stroke="black"/>
<polygon class="arrowhead" points="344,176 332,170.4 332,181.6 " fill="black" transform="rotate(90,336,176)"/> <polygon class="arrowhead" points="344,176 332,170.4 332,181.6 " fill="black" transform="rotate(90,336,176)"/>
<polygon class="arrowhead" points="312,96 300,90.4 300,101.6" fill="black" transform="rotate(0,304,96)"/> <polygon class="arrowhead" points="312,96 300,90.4 300,101.6" fill="black" transform="rotate(0,304,96)"/>
<polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill="black" transform="rotate(180,160,96)"/> <polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill="black" transform="rotate(180,160,96)"/>
<polygon class="arrowhead" points="144,184 132,178.4 132,189.6 " fill="black" transform="rotate(90,136,184)"/> <polygon class="arrowhead" points="144,184 132,178.4 132,189.6 " fill="black" transform="rotate(90,136,184)"/>
<g class="text"> <g class="text">
<text x="368" y="52">RFC9543</text> <text x="368" y="52">RFC 9543</text>
<text x="416" y="52">NSC</text> <text x="416" y="52">NSC</text>
<text x="68" y="68">Customer</text> <text x="68" y="68">Customer</text>
<text x="124" y="68">Site</text> <text x="124" y="68">Site</text>
<text x="88" y="84">Orchestration</text> <text x="88" y="84">Orchestration</text>
<text x="204" y="84">IETF</text> <text x="204" y="84">IETF</text>
<text x="256" y="84">APIs/DM</text> <text x="256" y="84">APIs/DM</text>
<text x="352" y="84">(Provider</text> <text x="352" y="84">(Provider</text>
<text x="424" y="84">Network</text> <text x="424" y="84">Network</text>
<text x="388" y="100">Orchestration)</text> <text x="388" y="100">Orchestration)</text>
<text x="144" y="164">-</text> <text x="144" y="164">-</text>
skipping to change at line 1139 skipping to change at line 1516
<text x="76" y="260">Site</text> <text x="76" y="260">Site</text>
<text x="392" y="260">Network</text> <text x="392" y="260">Network</text>
<text x="128" y="308">|</text> <text x="128" y="308">|</text>
<text x="236" y="308">AC</text> <text x="236" y="308">AC</text>
<text x="344" y="308">|</text> <text x="344" y="308">|</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.-------------. .----------------. .-------------. .----------------.
| | | RFC9543 NSC | | | | RFC 9543 NSC |
| Customer Site | | | | Customer Site | | |
| Orchestration | IETF APIs/DM |(Provider Network | | Orchestration | IETF APIs/DM |(Provider Network |
| |<----------------->| Orchestration) | | |<----------------->| Orchestration) |
'-------------' '----------------' '-------------' '----------------'
| | | |
| | | |
+---------------|-+ +-|---------------+ +---------------|-+ +-|---------------+
| v | | v | | v | | v |
| +--+ +--+ .1| 192.0.2.0/31 |.0+--+ | | +--+ +--+ .1| 192.0.2.0/31 |.0+--+ |
| |NF+.....+CE+---------------------------+PE| | | |NF+.....+CE+---------------------------+PE| |
skipping to change at line 1164 skipping to change at line 1541
|----------- AC -----------| |----------- AC -----------|
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec-mapping"> <section anchor="sec-mapping">
<name>Mapping 5G Network Slices to Transport Network Slices</name> <name>Mapping 5G Network Slices to Transport Network Slices</name>
<t>There are multiple options for mapping 5G Network Slices to TN slices :</t> <t>There are multiple options for mapping 5G Network Slices to TN slices :</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>1-to-N mapping:</dt>
<t>1 to N: <dd>A single 5G Network Slice can be mapped to multiple TN slices. For in
A single 5G Network Slice can be mapped to multiple TN slices (1 to N). For inst stance, consider the scenario depicted in <xref
ance, consider the scenario depicted in <xref target="_figure-5"/>, illustrating target="_figure-5"/>, which illustrates the separation of the 5G control
the separation of the 5G control plane and user plane in TN slices for a single plane and user plane in TN slices for a single 5G Enhanced Mobile
5G Enhanced Mobile Broadband (eMBB) network slice. It is important to note that Broadband (eMBB) network slice. It is important to note that this
this mapping can serve as an interim step to M to N mapping. Further details ab mapping can serve as an interim step to M-to-N mapping. Further
out this scheme are described in <xref target="sec-firstslice"/>.</t> details about this scheme are described in <xref
</li> target="sec-firstslice"/>.</dd>
<li> <dt>M-to-1 mapping:</dt>
<t>M to 1: <dd>Multiple 5G Network Slices may rely upon the same TN slice. In
Multiple 5G Network Slices may rely upon the same TN slice. In such a case, th such a case, the Service Level Agreement (SLA) differentiation of
e Service Level Agreement (SLA) differentiation of slices slices would be entirely controlled at the 5G control plane, for
would be entirely controlled at the 5G control plane, for example, with example, with appropriate placement strategies. This use case is
appropriate placement strategies: this use case is illustrated in illustrated in <xref target="_figure-6"/>, where a User Plane Function
<xref target="_figure-6"/>, where a User Plane Function (UPF) for the Ultra Rel (UPF) for the Ultra-Reliable Low-Latency Communication (URLLC) slice
iable Low Latency Communication (URLLC) slice is is instantiated at the edge cloud, close to the gNB
instantiated at the edge cloud, close to the gNB Centralized Unit User Plane (C CU-UP, to improve latency and jitter control. The 5G
U-UP), to improve control plane and the UPF for the eMBB slice are instantiated in the
latency and jitter control. The 5G control plane and the UPF regional cloud.</dd>
for eMBB slice are instantiated in the regional cloud.</t>
</li> <!-- [rfced] Will readers understand the ">>" notation here?
<li> We see it defined as "bitwise right shift", "logical right shift",
<t>M to N: and "arithmetic right shift of the two's complement integer representation
The 5G to TN slice mapping combines both of M by N binary digits" in various RFCs.
approaches with a mix of shared and dedicated associations. </t>
<t> Original:
In this scenario, a subset of the TN slices can be intended for sharing by multi In practice, for operational and scaling reasons, typically M to N
ple 5G Network Slices (e.g., the control plane TN slice is shared by multiple 5G would be used, with M >> N.
network Slices). </t> -->
<t>
In practice, for operational and scaling reasons, typically M to N would be used <dt>M-to-N mapping:</dt>
, with M &gt;&gt; N.</t> <dd><t>The mapping of 5G to TN slice combines both approaches with a mix
</li> of shared and dedicated associations. </t>
</ul> <t>In this scenario, a subset of the TN slices can be intended for
sharing by multiple 5G Network Slices (e.g., the control plane TN
slice is shared by multiple 5G Network Slices). </t> <t>In practice,
for operational and scaling reasons, M-to-N mapping would typically be u
sed,
with M &gt;&gt; N.</t>
</dd>
</dl>
<!-- [rfced] Titles of figures
a) Should "Site" be plural in this title as Figure 3 shows two sites?
Original:
Figure 3: Reference Design with Customer Site and Provider Network
Perhaps:
Figure 3: Reference Design with Customer Sites and Provider Network
b) Should the title of Figure 9 use "M" rather than "N"? We ask because
"N to 1" is not included in the list above the figure. The list only includes
"1 to N", "M to 1", and "M to N". Also, may revise the titles of Figures 8 and 9
in one of the following ways to improve readability?
Original:
Figure 8: 1 (5G Slice) to N (TN Slice) Mapping
Figure 9: N (5G Slice) to 1 (TN Slice) Mapping
Perhaps:
Figure 8: 1-to-N Mapping
Figure 9: M-to-1 Mapping
Or:
Figure 8: 1-to-N Mapping (Single 5G Slice to Multiple TN Slices)
Figure 9: M-to-1 Mapping (Multiple 5G Slices to Single TN Slice)
c) FYI - We added "Example of" to the title of Figure 16 to align with the
title of Figure 15.
Original:
Figure 15: Example of MPLS Hand-off with Option B
Figure 16: MPLS Hand-off with Option C
Updated:
Figure 15: Example of MPLS Handoff with Option B
Figure 16: Example of MPLS Handoff with Option C
d) Is "Ingress" correct in the title of Figure 21, or should it be updated to
"Egress"? Also, is "Output" needed? We included the title of Figure 20 below
for comparison.
Original:
Figure 20: Ingress Slice Admission Control (5QI-unaware Model)
Figure 21: Ingress Slice Admission control (5QI-unaware Model) - Output
Perhaps:
Figure 20: Ingress Slice Admission Control (5QI-Unaware Model)
Figure 21: Egress Slice Admission Control (5QI-Unaware Model)
e) FYI - We included "Model" to the parenthetical in these figure titles.
Original:
Figure 25: Ingress Slice Admission Control (5QI-Aware) - Hierarchical
Figure 26: Egress Slice Admission Control (5QI-Aware)
Perhaps:
Figure 25: Ingress Slice Admission Control (5QI-Aware Model) - Hierarchical
Figure 26: Egress Slice Admission Control (5QI-Aware Model)
f) We revised the figure titles below as follows to avoid awkward hyphenation
with "Mapping". For Figure 28, we also removed "PEs" for consistency with the
title of Figure 29.
For the title of Figure 17, should "Slice" be updated to "Network Slice", or
is the current okay?
Original:
Figure 17: Slice to TN QoS Mapping (5QI-Unaware Model)
Figure 22: Slice 5Q QoS to TN QoS Mapping (5QI-Aware Model)
Figure 28: Network Slice to PEs Underlay Transport Mapping (5QI-Unaware Model)
Figure 29: Network Slice to Underlay Transport Mapping (5QI-Aware Model)
Updated:
Figure 17: Mapping of Slice to TN QoS (5QI-Unaware Model)
Figure 22: Mapping of Slice 5Q QoS to TN QoS (5QI-Aware Model)
Figure 28: Mapping of Network Slice to Underlay Transport (5QI-Unaware Model)
Figure 29: Mapping of Network Slice to Underlay Transport (5QI-Aware Model)
-->
<figure anchor="_figure-5"> <figure anchor="_figure-5">
<name>1 (5G Slice) to N (TN Slice) Mapping</name> <name>1 (5G Slice) to N (TN Slice) Mapping</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="256" width="544" viewBox="0 0 544 256" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="256" width="544" viewBox="0 0 544 256" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,32 L 8,192" fill="none" stroke="black"/> <path d="M 8,32 L 8,192" fill="none" stroke="black"/>
<path d="M 24,80 L 24,112" fill="none" stroke="black"/> <path d="M 24,80 L 24,112" fill="none" stroke="black"/>
<path d="M 24,144 L 24,176" fill="none" stroke="black"/> <path d="M 24,144 L 24,176" fill="none" stroke="black"/>
<path d="M 72,80 L 72,112" fill="none" stroke="black"/> <path d="M 72,80 L 72,112" fill="none" stroke="black"/>
<path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/>
<path d="M 112,64 L 112,88" fill="none" stroke="black"/> <path d="M 112,64 L 112,88" fill="none" stroke="black"/>
skipping to change at line 1388 skipping to change at line 1868
| | +--------------+ | | +--------------+
| Transport Network | | Transport Network |
+------------------------------+ +------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Note that the actual realization of the mapping depends on several <t>Note that the actual realization of the mapping depends on several
factors, such as the actual business cases, the NF vendor factors, such as the actual business cases, the NF vendor
capabilities, the NF vendor reference designs, as well as service capabilities, the NF vendor reference designs, as well as service
provider or even legal requirements.</t> provider or even legal requirements.</t>
<t>Mapping approaches that preserve the 5G slice identification in the T N (e.g., <xref target="sec-ip-hof"/>) may simplify required operations to map ba ck TN slices to 5G slices. However, such considerations are not detailed in this document because these are under the responsibility of the 3GPP orchestration d omain.</t> <t>Mapping approaches that preserve the 5G slice identification in the T N (e.g., the approach in <xref target="sec-ip-hof"/>) may simplify required oper ations to map TN slices back to 5G slices. However, such considerations are not detailed in this document because these are under the responsibility of the 3GPP orchestration domain.</t>
</section> </section>
<section anchor="sec-firstslice"> <section anchor="sec-firstslice">
<name>First 5G Slice versus Subsequent Slices</name> <name>First 5G Slice Versus Subsequent Slices</name>
<t>An operational 5G Network Slice incorporates both 5G control plane an d user plane capabilities. <t>An operational 5G Network Slice incorporates both 5G control plane an d user plane capabilities.
For instance, in some deployments, in the case of a slice based on split-CU in t For instance, in some deployments, in the case of a slice based on split CU in t
he RAN, both CU-UP and Centralized Unit Control Plane (CU-CP) may need to be dep he RAN, both CU-UP and CU-CP may need to be deployed along with the associated i
loyed along with the associated interfaces E1, F1-c, F1-u, N2, and N3 which are nterfaces E1, F1-c, F1-u, N2, and N3, which are conveyed in the TN. In this rega
conveyed in the TN. In this regard, the creation of the "first slice" can be sub rd, the creation of the "first slice" can be subject to a specific logic that do
ject to a specific logic that does not apply to subsequent slices. Let us consid es not apply to subsequent slices. Let us consider the example depicted in <xref
er the example depicted in <xref target="_figure-7"/> to illustrate this deploym target="_figure-7"/> to illustrate this deployment. In this example, the first
ent. In this example, the first 5G slice relies on the deployment of NF-CP and N 5G slice relies on the deployment of NF-CP and NF-UP functions together with two
F-UP functions together with two TN slices for control and user planes (TNS-CP a TN slices for the control and user planes (TNS-CP and TNS-UP1). Next, in many c
nd TNS-UP1). Next, in many cases, the deployment of a second slice relies solely ases, the deployment of a second slice relies solely on the instantiation of a U
on the instantiation of a UPF (NF-UP2) together with a dedicated user plane TN PF (NF-UP2) together with a dedicated TN slice for the user plane (TNS-UP2). Th
slice (TNS-UP2). The control plane of the first 5G slice is also updated to inte e control plane of the first 5G slice is also updated to integrate the second sl
grate the second slice: the TN slice (TNS-CP) and Network Functions (NF-CP) are ice; the TN slice (TNS-CP) and Network Functions (NF-CP) are shared.</t>
shared.</t> <t>The model described here, in which the control plane is shared among multiple
<ul empty="true"> slices, is likely to be common; it is not mandatory, though. Deployment models
<li> with a separate control plane for each slice are also possible.</t>
<t>The model described here, in which the control plane is shared am
ong multiple slices, is likely to be common; it is not mandatory, though. Deploy
ment models with a separate control plane for each slice are also possible.</t>
</li>
</ul>
<t>Section 6.1.2 of <xref target="NG.113"/> specifies that the <t>Section 6.1.2 of <xref target="NG.113"/> specifies that the
eMBB slice (SST-1 and no Slice Differentiator (SD)) should be supported globa lly. This 5G eMBB slice (SST-1 and no Slice Differentiator (SD)) should be supported globa lly. This 5G
slice would be the first slice in any 5G deployment.</t> slice would be the first slice in any 5G deployment.</t>
<figure anchor="_figure-7"> <figure anchor="_figure-7">
<name>First and Subsequent Slice Deployment</name> <name>First and Subsequent Slice Deployment</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="768" width="528" viewBox="0 0 528 768" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="768" width="528" viewBox="0 0 528 768" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,64 L 8,240" fill="none" stroke="black"/> <path d="M 8,64 L 8,240" fill="none" stroke="black"/>
<path d="M 8,352 L 8,544" fill="none" stroke="black"/> <path d="M 8,352 L 8,544" fill="none" stroke="black"/>
<path d="M 8,608 L 8,752" fill="none" stroke="black"/> <path d="M 8,608 L 8,752" fill="none" stroke="black"/>
skipping to change at line 1516 skipping to change at line 1992
<path d="M 376,656 L 424,656" fill="none" stroke="black"/> <path d="M 376,656 L 424,656" fill="none" stroke="black"/>
<path d="M 56,672 L 112,672" fill="none" stroke="black"/> <path d="M 56,672 L 112,672" fill="none" stroke="black"/>
<path d="M 160,672 L 376,672" fill="none" stroke="black"/> <path d="M 160,672 L 376,672" fill="none" stroke="black"/>
<path d="M 424,672 L 480,672" fill="none" stroke="black"/> <path d="M 424,672 L 480,672" fill="none" stroke="black"/>
<path d="M 144,704 L 392,704" fill="none" stroke="black"/> <path d="M 144,704 L 392,704" fill="none" stroke="black"/>
<path d="M 8,752 L 520,752" fill="none" stroke="black"/> <path d="M 8,752 L 520,752" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="16" y="36">(1)</text> <text x="16" y="36">(1)</text>
<text x="76" y="36">Deployment</text> <text x="76" y="36">Deployment</text>
<text x="132" y="36">of</text> <text x="132" y="36">of</text>
<text x="168" y="36">first</text> <text x="168" y="36">First</text>
<text x="204" y="36">5G</text> <text x="204" y="36">5G</text>
<text x="240" y="36">slice</text> <text x="240" y="36">Slice</text>
<text x="232" y="84">First</text> <text x="232" y="84">First</text>
<text x="268" y="84">5G</text> <text x="268" y="84">5G</text>
<text x="304" y="84">Slice</text> <text x="304" y="84">Slice</text>
<text x="80" y="148">NF-CP</text> <text x="80" y="148">NF-CP</text>
<text x="196" y="148">CP</text> <text x="196" y="148">CP</text>
<text x="220" y="148">TN</text> <text x="220" y="148">TN</text>
<text x="256" y="148">Slice</text> <text x="256" y="148">Slice</text>
<text x="316" y="148">(TNS-CP)</text> <text x="316" y="148">(TNS-CP)</text>
<text x="456" y="148">NF-CP</text> <text x="456" y="148">NF-CP</text>
<text x="80" y="212">NF-UP</text> <text x="80" y="212">NF-UP</text>
<text x="188" y="212">UP</text> <text x="188" y="212">UP</text>
<text x="212" y="212">TN</text> <text x="212" y="212">TN</text>
<text x="248" y="212">Slice</text> <text x="248" y="212">Slice</text>
<text x="312" y="212">(TNS-UP1)</text> <text x="312" y="212">(TNS-UP1)</text>
<text x="456" y="212">NF-UP</text> <text x="456" y="212">NF-UP</text>
<text x="232" y="276">Transport</text> <text x="232" y="276">Transport</text>
<text x="304" y="276">Network</text> <text x="304" y="276">Network</text>
<text x="16" y="324">(2)</text> <text x="16" y="324">(2)</text>
<text x="76" y="324">Deployment</text> <text x="76" y="324">Deployment</text>
<text x="132" y="324">of</text> <text x="132" y="324">of</text>
<text x="188" y="324">additional</text> <text x="188" y="324">Additional</text>
<text x="244" y="324">5G</text> <text x="244" y="324">5G</text>
<text x="280" y="324">slice</text> <text x="280" y="324">Slice</text>
<text x="324" y="324">with</text> <text x="324" y="324">with</text>
<text x="372" y="324">shared</text> <text x="372" y="324">Shared</text>
<text x="432" y="324">Control</text> <text x="432" y="324">Control</text>
<text x="488" y="324">Plane</text> <text x="488" y="324">Plane</text>
<text x="232" y="372">First</text> <text x="232" y="372">First</text>
<text x="268" y="372">5G</text> <text x="268" y="372">5G</text>
<text x="304" y="372">Slice</text> <text x="304" y="372">Slice</text>
<text x="80" y="436">NF-CP</text> <text x="80" y="436">NF-CP</text>
<text x="196" y="436">CP</text> <text x="196" y="436">CP</text>
<text x="220" y="436">TN</text> <text x="220" y="436">TN</text>
<text x="256" y="436">Slice</text> <text x="256" y="436">Slice</text>
<text x="316" y="436">(TNS-CP)</text> <text x="316" y="436">(TNS-CP)</text>
skipping to change at line 1597 skipping to change at line 2073
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| | | | | | | |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-UP+------+ UP TN Slice (TNS-UP1) +------+NF-UP| | | |NF-UP+------+ UP TN Slice (TNS-UP1) +------+NF-UP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
+----------------|------------------------------|---------------+ +----------------|------------------------------|---------------+
| | | |
| Transport Network | | Transport Network |
+------------------------------+ +------------------------------+
(2) Deployment of additional 5G slice with shared Control Plane (2) Deployment of additional 5G slice with shared control plane
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| First 5G Slice | | First 5G Slice |
| | | |
| +------------------------------+ | | +------------------------------+ |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-CP+------+ CP TN Slice (TNS-CP) +------+NF-CP| | | |NF-CP+------+ CP TN Slice (TNS-CP) +------+NF-CP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| SHARED | (SHARED) | SHARED | | SHARED | (SHARED) | SHARED |
| | | | | | | |
skipping to change at line 1628 skipping to change at line 2104
| |NF-UP2+-----+ UP TN Slice (TNS-UP2) +-----+NF-UP2| | | |NF-UP2+-----+ UP TN Slice (TNS-UP2) +-----+NF-UP2| |
| +------+ | +--------------------------+ | +------+ | | +------+ | +--------------------------+ | +------+ |
| | | | | | | |
| +------------------------------+ | | +------------------------------+ |
| | | |
| Second 5G Slice | | Second 5G Slice |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!-- [rfced] Is "to instruct" the correct word choice here? Or would "to
determine" or something else be an improvement?
Original:
TN slice mapping policies can be enforced by an operator (e.g.,
provided to a TN Orchestration or 5G NSO) to instruct whether
existing TN slices can be reused for handling a new slice service
creation request.
Perhaps:
TN slice mapping policies can be enforced by an operator (e.g.,
provided to a TN Orchestration or 5G NSO) to determine whether
existing TN slices can be reused for handling a new slice service
creation request.
-->
<t>TN slice mapping policies can be enforced by an operator (e.g., provi ded to a TN Orchestration or 5G NSO) to instruct whether existing TN slices can be reused for handling a new slice service creation request. Providing such a po licy is meant to better automate the realization of 5G slices and minimize the r ealization delay that might be induced by extra cycles to seek for operator vali dation.</t> <t>TN slice mapping policies can be enforced by an operator (e.g., provi ded to a TN Orchestration or 5G NSO) to instruct whether existing TN slices can be reused for handling a new slice service creation request. Providing such a po licy is meant to better automate the realization of 5G slices and minimize the r ealization delay that might be induced by extra cycles to seek for operator vali dation.</t>
</section> </section>
<section anchor="sec-over-rea-model"> <section anchor="sec-over-rea-model">
<name>Overview of the Transport Network Realization Model</name> <name>Overview of the Transport Network Realization Model</name>
<t>The realization model described in this document is depicted in <t>The realization model described in this document is depicted in
<xref target="_figure-high-level-qos"/>. The following building blocks are us <xref target="_figure-high-level-qos"/>. The following building blocks
ed:</t> are used:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>L2VPN <xref target="RFC4664"/> and/or L3VPN <xref target="RFC4364 <t>L2VPN <xref target="RFC4664"/> and/or L3VPN <xref
"/> service instances for logical separation: </t> target="RFC4364"/> service instances for logical separation: </t>
<t> <t>This realization model of transport for 5G slices assumes Layer
This realization model of transport for 5G slices assumes Layer 3 3 delivery for midhaul and backhaul transport connections and a
delivery for midhaul and backhaul transport connections, and a Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced
Layer 2 or Layer 3 delivery for Common Public Radio Interface (eCPRI) <xref target="ECPRI"/>
fronthaul connections. Enhanced Common Public Radio Interface (eCPRI) <xref targ supports both delivery models. L2VPN/L3VPN service instances might
et="ECPRI"/> supports both delivery models. L2VPN/L3VPN service instances might be used as a basic form of logical slice separation. Furthermore,
be using service instances results in an additional outer header (as
used as a basic form of logical slice separation. Furthermore, using packets are encapsulated/decapsulated at the nodes hosting service
service instances results in an additional outer header (as packets instances), providing clean discrimination between 5G QoS and TN
are encapsulated/decapsulated at the nodes hosting service instances) providing QoS, as explained in <xref target="sec-qos-map"/>. </t>
clean discrimination between 5G QoS and TN <t>Note that a variety of L2VPN mechanisms can be considered for
QoS, as explained in <xref target="sec-qos-map"/>. </t> slice realization. A non-comprehensive list is provided below:</t>
<t>
Note that a variety of L2VPN mechanisms can be considered for slice realization.
A non-comprehensive list is provided below: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Virtual Private LAN Service (VPLS) <xref target="RFC4761"/> < xref target="RFC4762"/></t> <t>Virtual Private LAN Service (VPLS) <xref target="RFC4761"/> < xref target="RFC4762"/></t>
</li> </li>
<li> <li>
<t>Virtual Private Wire Service (VPWS) (<xref section="3.1.1" se ctionFormat="of" target="RFC4664"/>)</t> <t>Virtual Private Wire Service (VPWS) (<xref section="3.1.1" se ctionFormat="of" target="RFC4664"/>)</t>
</li> </li>
<li> <li>
<t>Various flavors of EVPNs: <t>Various flavors of EVPNs:</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>VPWS EVPN <xref target="RFC8214"/>,</t> <t>VPWS EVPN <xref target="RFC8214"/>,</t>
</li> </li>
<li> <li>
<t>Provider Backbone Bridging Combined with Ethernet VPNs (P BB-EVPNs) <xref target="RFC7623"/>,</t> <t>Provider Backbone Bridging combined with EVPN (PBB-EVPN) <xref target="RFC7623"/>,</t>
</li> </li>
<li> <li>
<t>EVPN over MPLS <xref target="RFC7432"/>, and</t> <t>EVPN over MPLS <xref target="RFC7432"/>, and</t>
</li> </li>
<li> <li>
<t>EVPN over Virtual Extensible LAN (VXLAN) <xref target="RF C8365"/>.</t> <t>EVPN over Virtual Extensible LAN (VXLAN) <xref target="RF C8365"/>.</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t> <t>The use of VPNs for realizing Network Slices is briefly described
The use of VPNs for realizing Network Slices is briefly described in Appendix A. in <xref section="A.4" target="RFC9543"/>.</t>
4 of <xref target="RFC9543"/>.</t>
</li> </li>
<li> <li>
<t>Fine-grained resource control at the PE: </t> <t>Fine-grained resource control at the PE: </t>
<t> <t>This is sometimes called "admission control" or "traffic
This is sometimes called 'admission control' or 'traffic conditioning". The main purpose is the enforcement of the
conditioning'. The main purpose is the enforcement of the bandwidth contract for the slice right at the edge of the provider
bandwidth contract for the slice right at the edge of the network where the traffic is handed off between the customer site
provider network where the traffic is handed-off between the and the provider network. </t>
customer site and the provider network. </t>
<t> <t>The method used here is granular ingress policing (rate
The method used here is granular ingress policing (rate limiting) limiting) to enforce contracted bandwidths per slice and,
to enforce contracted bandwidths per slice and, potentially, per potentially, per traffic class within the slice. Traffic above
traffic class within the slice. Traffic above the enforced rate might be the enforced rate might be immediately dropped or marked as high
immediately dropped, or marked as high drop-probability traffic, drop-probability traffic, which is more likely to be dropped
which is more likely to be dropped somewhere inside the provider network if somewhere inside the provider network if congestion occurs. In
congestion occurs. In the egress direction at the PE node, the egress direction at the PE node, hierarchical
hierarchical schedulers/shapers can be deployed, schedulers/shapers can be deployed, providing guaranteed rates per
providing guaranteed rates per slice, as well as guarantees per slice, as well as guarantees per traffic class within each slice.
traffic class within each slice. </t> </t>
<t> <t>For managed CEs, edge admission control can be distributed
For managed CEs, edge admission control can be distributed between CEs between CEs and PEs, where part of the admission control is
and PEs, where a part of the admission control is implemented on the CE implemented on the CE and the other part on the PE.</t>
and other part of the admission control is implemented on the PE.</t>
</li> </li>
<li> <li>
<t>Coarse-grained resource control at the transit (non-attachment <t>Coarse-grained resource control at the transit links (non-attachm
circuits) links in the provider network, using a single NRP (called "base NRP" i ent
n <xref target="_figure-high-level-qos"/>), spanning the entire provider network circuits) in the provider network, using a single NRP
. (called "base NRP" in <xref target="_figure-high-level-qos"/>),
Transit nodes in the provider network do not maintain any state of individual sl spanning the entire provider network. Transit nodes in the
ices. provider network do not maintain any state of individual slices.
Instead, only a flat (non-hierarchical) QoS model is used on Instead, only a flat (non-hierarchical) QoS model is used on
transit links in the provider network, with up to 8 traffic classes. At the PE, transit links in the provider network, with up to 8 traffic
traffic-flows from multiple slice services are mapped classes. At the PE, traffic flows from multiple slice services
to the limited number of traffic classes used on provider network transit links. are mapped to the limited number of traffic classes used on
</t> transit links in the provider network.</t>
</li> </li>
<li> <li>
<t>Capacity planning/management for efficient usage of provider netw <t>Capacity planning/management for efficient usage of provider
ork resources: </t> network resources:</t>
<t> <!-- [rfced] This sentence may be difficult for readers to follow because of
The role of capacity planning/management is to ensure the provider network the many "to.." phrases. How may we update?
capacity can be utilized without causing any bottlenecks. The
methods used here can range from careful network planning, to Original:
ensure a more or less equal traffic distribution (i.e., equal cost load The methods used here can range from careful network planning, to
balancing), to advanced TE techniques, with or ensure a more or less equal traffic distribution (i.e., equal cost
without bandwidth reservations, to force more consistent load load balancing), to advanced TE techniques, with or without
distribution even in non-ECMP friendly network topologies. See also <xref sectio bandwidth reservations, to force more consistent load distribution
n="8" sectionFormat="of" target="RFC9522"/>.</t> even in non-ECMP friendly network topologies.
Perhaps:
The methods used here can range from careful network planning that
ensures a more or less equal traffic distribution (i.e., equal-cost
load balancing) to advanced TE techniques, with or without
bandwidth reservations, that force more consistent load distribution,
even in non-ECMP-friendly network topologies.
-->
<t>The role of capacity planning/management is to ensure the
provider network capacity can be utilized without causing any
bottlenecks. The methods used here can range from careful network
planning, to ensure a more or less equal traffic distribution
(i.e., equal-cost load balancing), to advanced TE techniques, with
or without bandwidth reservations, to force more consistent load
distribution, even in non-ECMP-friendly network topologies. See
also <xref section="8" sectionFormat="of" target="RFC9522"/>.</t>
</li> </li>
</ul> </ul>
<figure anchor="_figure-high-level-qos"> <figure anchor="_figure-high-level-qos">
<name>Resource Allocation Slicing Model with a Single NRP</name> <name>Resource Allocation Slicing Model with a Single NRP</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="416" width="584" viewBox="0 0 584 416" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="416" width="584" viewBox="0 0 584 416" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 56,64 L 56,288" fill="none" stroke="black"/> <path d="M 56,64 L 56,288" fill="none" stroke="black"/>
<path d="M 96,112 L 96,240" fill="none" stroke="black"/> <path d="M 96,112 L 96,240" fill="none" stroke="black"/>
<path d="M 144,64 L 144,288" fill="none" stroke="black"/> <path d="M 144,64 L 144,288" fill="none" stroke="black"/>
<path d="M 208,128 L 208,224" fill="none" stroke="black"/> <path d="M 208,128 L 208,224" fill="none" stroke="black"/>
skipping to change at line 1920 skipping to change at line 2436
N | | | | | | | | | | N | | | | | | | | | |
S *<---+ | | | | | | +--->* S *<---+ | | | | | | +--->*
# | | | +-----+ +-----+ | | | # | | | +-----+ +-----+ | | |
2 *<---+ | | +--->* 2 *<---+ | | +--->*
-- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- | -- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
| : | | : | | : | | : |
+-----:----+ +----:-----+ +-----:----+ +----:-----+
: : : :
'..............................................' '..............................................'
* SDP, with fine-grained QoS (dedicated resources per Network Slice) * SDP, with fine-grained QoS (dedicated resources per Network
Slice)
o Coarse-grained QoS, with resources shared by all Network Slices o Coarse-grained QoS, with resources shared by all Network Slices
... Base NRP ... Base NRP
-- -- Network Slice -- -- Network Slice
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>P nodes shown in <xref target="_figure-high-level-qos"/> are routers that do not interface with customer devices. See <xref section="5.3.1" sectionFo rmat="of" target="RFC4026"/>.</t> <t>The P nodes shown in <xref target="_figure-high-level-qos"/> are rout ers that do not interface with customer devices. See <xref section="5.3.1" secti onFormat="of" target="RFC4026"/>.</t>
<t>This document does not describe in detail how to manage an L2VPN or L 3VPN, as this is already well-documented. For example, the reader may refer to < xref target="RFC4176"/> and <xref target="RFC6136"/> for such details.</t> <t>This document does not describe in detail how to manage an L2VPN or L 3VPN, as this is already well-documented. For example, the reader may refer to < xref target="RFC4176"/> and <xref target="RFC6136"/> for such details.</t>
</section> </section>
</section> </section>
<section anchor="sec-handoff-domains"> <section anchor="sec-handoff-domains">
<name>Hand-off Between Domains</name> <name>Handoff Between Domains</name>
<t>The 5G control plane relies upon 32-bit S-NSSAIs for slice <t>The 5G control plane relies upon 32-bit S-NSSAIs for slice
identification. The S-NSSAI is not visible to the transport domain. identification. The S-NSSAI is not visible to the transport domain.
So instead, 5G network functions can expose the 5G slices to the transport So instead, 5G network functions can expose the 5G slices to the transport
domain by mapping to explicit Layer 2 or Layer 3 identifiers, such as VLAN-ID s, IP domain by mapping to explicit Layer 2 or Layer 3 identifiers, such as VLAN-ID s, IP
addresses, or Differentiated Services Code Point (DSCP) values. The following sections list a few hand-off methods for slice mapping addresses, or Differentiated Services Code Point (DSCP) values. The following subsections list a few handoff methods for slice mapping
between customer sites and provider networks.</t> between customer sites and provider networks.</t>
<t>More details about the mapping between 3GPP and RFC 9543 Network Slices is provided in <xref target="I-D.ietf-teas-5g-network-slice-application"/>.</t> <t>More details about the mapping between 3GPP and RFC 9543 Network Slices is provided in <xref target="I-D.ietf-teas-5g-network-slice-application"/>.</t>
<t><!---
<!---
That document includes additional methods for mapping 5G slices to TN slices (e.g., source UDP port number), but these That document includes additional methods for mapping 5G slices to TN slices (e.g., source UDP port number), but these
methods are not discussed here because of the shortcomings of these methods ( e.g., load balancing, NAT). methods are not discussed here because of the shortcomings of these methods ( e.g., load balancing, NAT).
--> -->
</t>
<section anchor="sec-vlan-handoff"> <section anchor="sec-vlan-handoff">
<name>VLAN Hand-off</name> <name>VLAN Handoff</name>
<t>In this option, the RFC 9543 Network Slice, fulfilling connectivity <t>In this option, the RFC 9543 Network Slice, fulfilling connectivity
requirements between NFs that belong to a 5G slice, is represented at an SDP requirements between NFs that belong to a 5G slice, is represented at an SDP
by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in <xr ef target="_figure-vlan-hand-off"/>.</t> by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in <xr ef target="_figure-vlan-hand-off"/>.</t>
<figure anchor="_figure-vlan-hand-off"> <figure anchor="_figure-vlan-hand-off">
<name>Example of 5G Slice with VLAN Hand-off Providing End-to-End Conn ectivity</name> <name>Example of 5G Slice with VLAN Handoff Providing End-to-End Conne ctivity</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="288" width="616" viewBox="0 0 616 288" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="288" width="616" viewBox="0 0 616 288" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,96 L 8,192" fill="none" stroke="black"/> <path d="M 8,96 L 8,192" fill="none" stroke="black"/>
<path d="M 16,256 L 16,272" fill="none" stroke="black"/> <path d="M 16,256 L 16,272" fill="none" stroke="black"/>
<path d="M 64,96 L 64,192" fill="none" stroke="black"/> <path d="M 64,96 L 64,192" fill="none" stroke="black"/>
<path d="M 96,64 L 96,120" fill="none" stroke="black"/> <path d="M 96,64 L 96,120" fill="none" stroke="black"/>
<path d="M 128,96 L 128,192" fill="none" stroke="black"/> <path d="M 128,96 L 128,192" fill="none" stroke="black"/>
<path d="M 144,64 L 144,96" fill="none" stroke="black"/> <path d="M 144,64 L 144,96" fill="none" stroke="black"/>
<path d="M 144,192 L 144,224" fill="none" stroke="black"/> <path d="M 144,192 L 144,224" fill="none" stroke="black"/>
<path d="M 176,96 L 176,192" fill="none" stroke="black"/> <path d="M 176,96 L 176,192" fill="none" stroke="black"/>
skipping to change at line 2053 skipping to change at line 2571
| | | | | | | | | | | | | | | | | | | |
+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+ +------+ AC +-+---+ Network +---+-+ AC +-----+ +------+
| | | |
+------------------+ +------------------+
+ Logical interface represented by a VLAN on a physical interface + Logical interface represented by a VLAN on a physical interface
* SDP * SDP
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!-- [rfced] We do not see "F2" used elsewhere in the document. Will readers
understand what this refers to?
Original:
Since the 5G
interfaces are IP-based interfaces (with an exception of the F2
fronthaul-interface, where eCPRI with Ethernet encapsulation is
used), this VLAN is typically not transported across the provider
network.
-->
<t>Each VLAN <t>Each VLAN
represents a distinct logical interface on the ACs; represents a distinct logical interface on the ACs and
hence it provides the possibility to place these logical interfaces hence provides the possibility to place these logical interfaces
in distinct Layer 2 or Layer 3 service instances and implement separation in distinct Layer 2 or Layer 3 service instances and implement separation
between slices via service instances. Since the 5G interfaces are IP-based between slices via service instances. Since the 5G interfaces are IP-based
interfaces (with an exception of the F2 fronthaul-interface, where eCPRI with Ethernet encapsulation is used), this interfaces (with the exception of the F2 fronthaul interface, where eCPRI wit h Ethernet encapsulation is used), this
VLAN is typically not transported across the provider network. Typically, VLAN is typically not transported across the provider network. Typically,
it has only local significance at a particular SDP. For it has only local significance at a particular SDP. For
simplification, a deployment may rely on the same VLAN identifier simplification, a deployment may rely on the same VLAN identifier
for all ACs. However, that may not be always possible. As such, SDPs for a sa for all ACs. However, that may not be always possible. As such, SDPs for the
me slice at same slice at
different locations may use different VLAN values. Therefore, a different locations may use different VLAN values. Therefore, a table mappin
VLAN to RFC 9543 Network Slice mapping table is maintained for each g
VLANs to RFC 9543 Network Slices is maintained for each
AC, and the VLAN allocation is coordinated between customer orchestration and AC, and the VLAN allocation is coordinated between customer orchestration and
provider orchestration.</t> provider orchestration.</t>
<t>While VLAN hand-off is simple for NFs, it adds complexity at the prov ider network because of the requirement of maintaining <t>While VLAN handoff is simple for NFs, it adds complexity at the provi der network because of the requirement of maintaining
mapping tables for each SDP and performing a configuration task for new VLANs and mapping tables for each SDP and performing a configuration task for new VLANs and
IP subnet for every slice on every AC.</t> IP subnet for every slice on every AC.</t>
</section> </section>
<section anchor="sec-ip-hof"> <section anchor="sec-ip-hof">
<name>IP Hand-off</name> <name>IP Handoff</name>
<t>In this option, an explicit mapping between source/destination IP add resses and <t>In this option, an explicit mapping between source/destination IP add resses and
slice's specific S-NSSAI is used. The mapping can have either local (e.g., a slice's specific S-NSSAI is used. The mapping can have either local (e.g.,
pertaining to single NF attachment) or global TN significance. The mapping ca pertaining to a single NF attachment) or global TN significance. The mapping
n can
be realized in multiple ways, including (but not limited to):</t> be realized in multiple ways, including (but not limited to):</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>S-NSSAI to a dedicated IP address for each NF</t> <t>S-NSSAI to a dedicated IP address for each NF</t>
</li> </li>
<li> <li>
<t>S-NSSAI to a pool of IP addresses for global TN deployment</t> <t>S-NSSAI to a pool of IP addresses for global TN deployment</t>
</li> </li>
<li> <li>
<t>S-NSSAI to a subset of bits of an IP address</t> <t>S-NSSAI to a subset of bits of an IP address</t>
</li> </li>
<li> <li>
<t>S-NSSAI to a DSCP value</t> <t>S-NSSAI to a DSCP value</t>
</li> </li>
<li> <li>
<t>S-NSSAI to SRv6 Locators or Segment Identifiers (SIDs) <xref targ et="RFC8986"/></t> <t>S-NSSAI to SRv6 Locators or Segment Identifiers (SIDs) <xref targ et="RFC8986"/></t>
</li> </li>
<li> <li>
<t>Use a deterministic algorithm to map S-NSAAI to an IP subnet, pre fix, or pools. For example, adaptations to the algorithm defined in <xref target ="RFC7422"/> may be considered.</t> <t>Use of a deterministic algorithm to map S-NSSAI to an IP subnet, prefix, or pools. For example, adaptations to the algorithm defined in <xref tar get="RFC7422"/> may be considered.</t>
</li> </li>
</ul> </ul>
<t>Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for slice-related <t>Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for slice-related
policy enforcement in the Transport Network (e.g., Differentiated Services, policy enforcement in the Transport Network (e.g., differentiated services,
traffic steering, bandwidth allocation, security policies, or monitoring).</t traffic steering, bandwidth allocation, security policies, and monitoring).</
> t>
<t>One example of the IP hand-off realization is the arrangement, where <t>One example of the IP handoff realization is the arrangement in which
the slices in the TN the slices in the TN
domain are instantiated using IP tunnels (e.g., IPsec or GTP-U tunnels) domain are instantiated using IP tunnels (e.g., IPsec or GTP-U tunnels)
established between NFs, as depicted in <xref target="_figure-ip-hand-off"/>. The transport for established between NFs, as depicted in <xref target="_figure-ip-hand-off"/>. The transport for
a single 5G slice might be constructed with multiple such tunnels, since a a single 5G slice might be constructed with multiple such tunnels, since a
typical 5G slice contains many NFs - especially DUs and CUs. If a shared NF ( typical 5G slice contains many NFs, especially DUs and CUs. If a shared NF (i
i.e., .e.,
an NF that serves multiple slices, for example, a shared DU) is deployed, mul an NF that serves multiple slices, such as a shared DU) is deployed, multiple
tiple tunnels from the shared NF are established, each tunnel representing a single
tunnels from shared NF are established, each tunnel representing a single sli slice.</t>
ce.</t>
<figure anchor="_figure-ip-hand-off"> <figure anchor="_figure-ip-hand-off">
<name>Example of 5G Slice with IP Hand-off Providing End-to-End Connec tivity</name> <name>Example of 5G Slice with IP Handoff Providing End-to-End Connect ivity</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="552" viewBox="0 0 552 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="552" viewBox="0 0 552 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,80 L 8,176" fill="none" stroke="black"/> <path d="M 8,80 L 8,176" fill="none" stroke="black"/>
<path d="M 64,80 L 64,96" fill="none" stroke="black"/> <path d="M 64,80 L 64,96" fill="none" stroke="black"/>
<path d="M 64,160 L 64,176" fill="none" stroke="black"/> <path d="M 64,160 L 64,176" fill="none" stroke="black"/>
<path d="M 128,80 L 128,96" fill="none" stroke="black"/> <path d="M 128,80 L 128,96" fill="none" stroke="black"/>
<path d="M 128,160 L 128,176" fill="none" stroke="black"/> <path d="M 128,160 L 128,176" fill="none" stroke="black"/>
<path d="M 144,48 L 144,80" fill="none" stroke="black"/> <path d="M 144,48 L 144,80" fill="none" stroke="black"/>
<path d="M 144,176 L 144,208" fill="none" stroke="black"/> <path d="M 144,176 L 144,208" fill="none" stroke="black"/>
<path d="M 176,80 L 176,96" fill="none" stroke="black"/> <path d="M 176,80 L 176,96" fill="none" stroke="black"/>
skipping to change at line 2215 skipping to change at line 2745
| | | | | | | | | | | | | | | | | | | |
+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+ +------+ AC +-+---+ Network +---+-+ AC +-----+ +------+
| | | |
+------------------+ +------------------+
o Tunnel (IPsec, GTP-U, etc.) termination point o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP * SDP
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>As opposed to the VLAN hand-off case (<xref target="sec-vlan-handoff" <t>As opposed to the VLAN handoff case (<xref target="sec-vlan-handoff"/
/>), there is no logical interface representing >), there is no logical interface representing
a slice on the PE, hence all slices are handled within a single service insta a slice on the PE; hence, all slices are handled within a single service inst
nce. ance.
The IP and VLAN hand-offs are not mutually exclusive, but instead could be us The IP and VLAN handoffs are not mutually exclusive but instead could be used
ed
concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping table simila r to concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping table simila r to
the VLAN Hand-off solution is needed (<xref target="sec-vlan-handoff"/>).</t> the VLAN handoff solution is needed (<xref target="sec-vlan-handoff"/>).</t>
<t>The mapping table can be simplified if, for example, IPv6 addressing is used to <t>The mapping table can be simplified if, for example, IPv6 addressing is used to
address NFs. An IPv6 address is a 128-bit long field, while the S-NSSAI is a address NFs. An IPv6 address is a 128-bit field, while the S-NSSAI is a
32-bit field: Slice/Service Type (SST): 8 bits, Slice Differentiator (SD): 24 32-bit field: The Slice/Service Type (SST) is 8 bits, and the Slice Different
bits. 32 bits, out of 128 bits of the IPv6 address, may be used to encode the iator (SD) is 24
S-NSSAI, which makes an IP to Slice mapping table unnecessary.</t> bits. Out of the 128 bits of the IPv6 address, 32 bits may be used to encode
the
S-NSSAI, which makes an IP-to-slice mapping table unnecessary.</t>
<t>The S-NSSAI/IPv6 mapping is a local IPv6 address allocation method to NFs not disclosed to on-path nodes. IP forwarding is not altered by this method and is <t>The S-NSSAI/IPv6 mapping is a local IPv6 address allocation method to NFs not disclosed to on-path nodes. IP forwarding is not altered by this method and is
still achieved following BCP 198 <xref target="RFC7608"/>. Intermediary TN no des are not required to associate any additional semantic with IPv6 address.</t> still achieved following BCP 198 <xref target="RFC7608"/>. Intermediary TN no des are not required to associate any additional semantic with the IPv6 address. </t>
<t>However, operators using such mapping methods should be aware of the implications <t>However, operators using such mapping methods should be aware of the implications
of any change of S-NSSAI on the IPv6 addressing plans. For example, modificat ions of the S-NSSAIs in-use will require of any change of S-NSSAI on the IPv6 addressing plans. For example, modificat ions of the S-NSSAIs in use will require
updating the IP addresses used by NFs involved in the associated slices.</t> updating the IP addresses used by NFs involved in the associated slices.</t>
<t>An Example of local IPv6 addressing plan for NFs is provided in <xref target="sec-v6-ex"/></t> <t>An example of a local IPv6 addressing plan for NFs is provided in <xr ef target="sec-v6-ex"/>.</t>
</section> </section>
<section anchor="sec-mpls-ho"> <section anchor="sec-mpls-ho">
<name>MPLS Label Hand-off</name> <name>MPLS Label Handoff</name>
<t>In this option, the service instances representing different slices <t>In this option, the service instances representing different slices
are created directly on the NF, or within the customer site are created directly on the NF, or within the customer site
hosting the NF, and attached to the provider network. Therefore, the packet hosting the NF, and attached to the provider network. Therefore, the packet
is encapsulated outside the provider network with MPLS is encapsulated outside the provider network with MPLS
encapsulation or MPLS-in-UDP encapsulation <xref target="RFC7510"/>, dependin g on the capability encapsulation or MPLS-in-UDP encapsulation <xref target="RFC7510"/>, dependin g on the capability
of the customer site, with the service label depicting of the customer site, with the service label depicting
the slice.</t> the slice.</t>
<t>There are three major methods (based upon <xref section="10" sectionF ormat="of" target="RFC4364"/>) for interconnecting MPLS services over multiple s ervice domains:</t> <t>There are three major methods (based upon <xref section="10" sectionF ormat="of" target="RFC4364"/>) for interconnecting MPLS services over multiple s ervice domains:</t>
<dl> <dl>
<dt>Option A (<xref target="sec-10a"/>):</dt> <dt>Option A (<xref target="sec-10a"/>):</dt>
<dd> <dd>
<t>VRF-to-VRF connections.</t> <t>VRF-to-VRF connections.</t>
</dd> </dd>
<dt>Option B (<xref target="sec-10b"/>):</dt> <dt>Option B (<xref target="sec-10b"/>):</dt>
<dd> <dd>
<t>redistribution of labeled VPN routes with next-hop <t>Redistribution of labeled VPN routes with next-hop
change at domain boundaries.</t> change at domain boundaries.</t>
</dd> </dd>
<dt>Option C (<xref target="sec-10c"/>):</dt> <dt>Option C (<xref target="sec-10c"/>):</dt>
<dd> <dd>
<t>redistribution of labeled VPN routes without next-hop <t>Redistribution of labeled VPN routes without next-hop
change and redistribution of labeled transport routes with next-hop change and redistribution of labeled transport routes with next-hop
change at domain boundaries.</t> change at domain boundaries.</t>
</dd> </dd>
</dl> </dl>
<t><xref target="_figure-51"/> illustrates the use of service-aware CE ( <xref target="sec-ce"/>) for the deployment discussed in Sections <xref format=" counter" target="sec-10b"/> and <xref format="counter" target="sec-10c"/>.</t> <t><xref target="_figure-51"/> illustrates the use of service-aware CE ( <xref target="sec-ce"/>) for the deployment discussed in Sections <xref format=" counter" target="sec-10b"/> and <xref format="counter" target="sec-10c"/>.</t>
<figure anchor="_figure-51"> <figure anchor="_figure-51">
<name>Example of MPLS-based Attachment Circuit</name> <name>Example of MPLS-Based Attachment Circuit</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="224" width="440" viewBox="0 0 440 224" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="224" width="440" viewBox="0 0 440 224" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,32 L 8,208" fill="none" stroke="black"/> <path d="M 8,32 L 8,208" fill="none" stroke="black"/>
<path d="M 80,176 L 80,208" fill="none" stroke="black"/> <path d="M 80,176 L 80,208" fill="none" stroke="black"/>
<path d="M 104,128 L 104,176" fill="none" stroke="black"/> <path d="M 104,128 L 104,176" fill="none" stroke="black"/>
<path d="M 128,32 L 128,128" fill="none" stroke="black"/> <path d="M 128,32 L 128,128" fill="none" stroke="black"/>
<path d="M 144,128 L 144,176" fill="none" stroke="black"/> <path d="M 144,128 L 144,176" fill="none" stroke="black"/>
<path d="M 168,176 L 168,208" fill="none" stroke="black"/> <path d="M 168,176 L 168,208" fill="none" stroke="black"/>
<path d="M 296,128 L 296,192" fill="none" stroke="black"/> <path d="M 296,128 L 296,192" fill="none" stroke="black"/>
<path d="M 312,32 L 312,128" fill="none" stroke="black"/> <path d="M 312,32 L 312,128" fill="none" stroke="black"/>
skipping to change at line 2321 skipping to change at line 2852
| | | MPLS-based AC | | | | | | MPLS-based AC | | |
| | CE +------------------+ PE | | | | CE +------------------+ PE | |
| +--+----+--+ | | | | +--+----+--+ | | |
| | VRF foo | +-+--+ | | | VRF foo | +-+--+ |
+--------+----------+ +--------------+ +--------+----------+ +--------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<section anchor="sec-10a"> <section anchor="sec-10a">
<name>Option A</name> <name>Option A</name>
<t>This option is not based on MPLS label hand-off, but VLAN hand-off, described in <xref target="sec-vlan-handoff"/>.</t> <t>This option is based on the VLAN handoff, described in <xref target ="sec-vlan-handoff"/>; it is not based on the MPLS label handoff.</t>
</section> </section>
<section anchor="sec-10b"> <section anchor="sec-10b">
<name>Option B</name> <name>Option B</name>
<!-- [rfced] Please confirm that "compute" (noun) is the correct word choice
here.
Original:
These L3VPN service instances are instantiated in
the customer site which could be, for example, either on the compute
that hosts mobile NFs (Figure 15, left-hand side) or within the DC/
cloud infrastructure itself (e.g., on the top of the rack or leaf
switch within cloud IP fabric (Figure 15, right-hand side)).
-->
<t>In this option, L3VPN service instances are instantiated outside th e <t>In this option, L3VPN service instances are instantiated outside th e
provider network. These L3VPN service instances provider network. These L3VPN service instances
are instantiated in the customer site which could be, for example, either on the compute that hosts mobile NFs (<xref target="_figure-mpls-10b-hand-off"/>, l eft-hand side) or within the DC/cloud are instantiated in the customer site, which could be, for example, either on the compute that hosts mobile NFs (<xref target="_figure-mpls-10b-hand-off"/>, left-hand side) or within the DC/cloud
infrastructure itself (e.g., on the top of the rack or leaf switch infrastructure itself (e.g., on the top of the rack or leaf switch
within cloud IP fabric (<xref target="_figure-mpls-10b-hand-off"/>, right-han d side)). On the within cloud IP fabric (<xref target="_figure-mpls-10b-hand-off"/>, right-han d side)). On the
AC connected to a PE, packets are already MPLS AC connected to a PE, packets are already MPLS
encapsulated (or MPLS-in-UDP/MPLS-in-IP encapsulated, if cloud or compute encapsulated (or MPLS-in-UDP/MPLS-in-IP encapsulated, if cloud or compute
infrastructure don't support MPLS encapsulation). Therefore, infrastructure don't support MPLS encapsulation). Therefore,
the PE uses neither a VLAN nor an IP address for slice the PE uses neither a VLAN nor an IP address for slice
identification at the SDP, but instead uses the MPLS label.</t> identification at the SDP but instead uses the MPLS label.</t>
<figure anchor="_figure-mpls-10b-hand-off"> <figure anchor="_figure-mpls-10b-hand-off">
<name>Example of MPLS Hand-off with Option B</name> <name>Example of MPLS Handoff with Option B</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="416" width="568" viewBox="0 0 568 416" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="416" width="568" viewBox="0 0 568 416" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,208 L 8,336" fill="none" stroke="black"/> <path d="M 8,208 L 8,336" fill="none" stroke="black"/>
<path d="M 24,240 L 24,304" fill="none" stroke="black"/> <path d="M 24,240 L 24,304" fill="none" stroke="black"/>
<path d="M 40,208 L 40,240" fill="none" stroke="black"/> <path d="M 40,208 L 40,240" fill="none" stroke="black"/>
<path d="M 48,304 L 48,336" fill="none" stroke="black"/> <path d="M 48,304 L 48,336" fill="none" stroke="black"/>
<path d="M 64,192 L 64,240" fill="none" stroke="black"/> <path d="M 64,192 L 64,240" fill="none" stroke="black"/>
<path d="M 80,240 L 80,304" fill="none" stroke="black"/> <path d="M 80,240 L 80,304" fill="none" stroke="black"/>
<path d="M 136,240 L 136,304" fill="none" stroke="black"/> <path d="M 136,240 L 136,304" fill="none" stroke="black"/>
<path d="M 152,208 L 152,240" fill="none" stroke="black"/> <path d="M 152,208 L 152,240" fill="none" stroke="black"/>
skipping to change at line 2512 skipping to change at line 3054
| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ | | +--+---+ +-+---+ +---+-+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 | | CS1| | Network | | L2/L3 CS2 |
+----+ +---------------+ +---------------------+ +----+ +---------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS labels) # Service instances (with unique MPLS labels)
* SDP * SDP
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!-- [rfced] Should "COM-1" here be updated to "COM=1" to match the usage in
Figure 15?
Original:
For example, in Figure 15, for the slice identified with
COM-1, the PE advertises a dynamically allocated label A".
Perhaps:
For example, in Figure 15, for the slice identified with
COM=1, the PE advertises a dynamically allocated label A".
-->
<t>MPLS labels are allocated dynamically in Option B <t>MPLS labels are allocated dynamically in Option B
deployments, where at the domain boundaries service prefixes are deployments, where, at the domain boundaries, service prefixes are
reflected with next-hop self, and a new label is dynamically allocated, reflected with next-hop self (nhs), and a new label is dynamically allocated,
as visible in <xref target="_figure-mpls-10b-hand-off"/> (e.g., labels A, A', as shown in <xref target="_figure-mpls-10b-hand-off"/> (e.g., labels A, A', a
and A" for the first depicted slice). Therefore, for any slice-specific per-ho nd A" for the first depicted slice). Therefore, for any slice-specific per-hop
p
behavior at the provider network edge, the PE needs to determine behavior at the provider network edge, the PE needs to determine
which label represents which slice. In the BGP control plane, when which label represents which slice. In the BGP control plane, when
exchanging service prefixes over an AC, each slice might be represented by a unique BGP community, so exchanging service prefixes over an AC, each slice might be represented by a unique BGP community, so
tracking label assignment to the slice might be possible. For example, in tracking label assignment to the slice might be possible. For example, in
<xref target="_figure-mpls-10b-hand-off"/>, for the slice identified with COM -1, the PE advertises a <xref target="_figure-mpls-10b-hand-off"/>, for the slice identified with COM -1, the PE advertises a
dynamically allocated label A". Since, based on the community, the dynamically allocated label A". Since, based on the community, the
label to slice association is known, the PE can use this dynamically label-to-slice association is known, the PE can use this dynamically
allocated label A" to identify incoming packets as belonging to "slice 1" allocated label A" to identify incoming packets as belonging to "slice 1"
and execute appropriate edge per-hop behavior.</t> and execute appropriate edge per-hop behavior.</t>
<t>It is worth noting that slice identification in the BGP control pla ne <t>It is worth noting that slice identification in the BGP control pla ne
might be with per-prefix granularity. In the extreme case, each prefix can h ave might be with per-prefix granularity. In the extreme case, each prefix can h ave a
different community representing a different slice. Depending on the different community representing a different slice. Depending on the
business requirements, each slice could be represented by a different business requirements, each slice could be represented by a different
service instance as outlined in <xref target="_figure-mpls-10b-hand-off"/>. In that case, the route service instance as outlined in <xref target="_figure-mpls-10b-hand-off"/>. In that case, the route
target extended community (<xref section="4" sectionFormat="of" target="RFC43 60"/>) might be used as slice differentiator. In target extended community (<xref section="4" sectionFormat="of" target="RFC43 60"/>) might be used as a slice differentiator. In
other deployments, all prefixes (representing different slices) other deployments, all prefixes (representing different slices)
might be handled by a single 'mobile' service instance, and some other might be handled by a single "mobile" service instance, and some other
BGP attribute (e.g., a standard community <xref target="RFC1997"/>) might be used for slice BGP attribute (e.g., a standard community <xref target="RFC1997"/>) might be used for slice
differentiation. There could be also a deployment option that groups multipl e differentiation. There could also be a deployment option that groups multipl e
slices together into a single service instance, resulting in a slices together into a single service instance, resulting in a
handful of service instances. In any case, fine-grained per-hop handful of service instances. In any case, fine-grained per-hop
behavior at the edge of provider network is possible.</t> behavior at the edge of provider network is possible.</t>
</section> </section>
<section anchor="sec-10c"> <section anchor="sec-10c">
<name>Option C</name> <name>Option C</name>
<t>Option B relies upon exchanging service prefixes between customer s ites <t>Option B relies upon exchanging service prefixes between customer s ites
and the provider network. This may lead to scaling challenges in large and the provider network. This may lead to scaling challenges in large-scale 5G
scale 5G deployments as the PE node needs to carry all service prefixes. deployments as the PE node needs to carry all service prefixes.
To alleviate this scaling challenge, in Option C, service prefixes are To alleviate this scaling challenge, in Option C, service prefixes are
exchanged between customer sites only. In doing so, the provider network is offl oaded from exchanged between customer sites only. In doing so, the provider network is offl oaded from
carrying, propagating, and programing appropriate forwarding entries carrying, propagating, and programming appropriate forwarding entries
for service prefixes.</t> for service prefixes.</t>
<t>Option C relies upon exchanging service prefixes via multi-hop BGP sessions <t>Option C relies upon exchanging service prefixes via multi-hop BGP sessions
between customer sites, without changing the NEXT_HOP BGP attribute. between customer sites, without changing the NEXT_HOP BGP attribute.
Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host routes, used as NEXT_HOP Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host routes, used as NEXT_HOP
for service prefixes, are exchanged via direct single-hop BGP sessions between for service prefixes, are exchanged via direct single-hop BGP sessions between
adjacent nodes in a customer site and a provider network, as depicted in <xref t arget="_figure-mpls-10c-hand-off"/>. adjacent nodes in a customer site and a provider network, as depicted in <xref t arget="_figure-mpls-10c-hand-off"/>.
As a result, a node in a customer site performs hierarchical next-hop resolution .</t> As a result, a node in a customer site performs hierarchical next-hop resolution .</t>
<figure anchor="_figure-mpls-10c-hand-off"> <figure anchor="_figure-mpls-10c-hand-off">
<name>MPLS Hand-off with Option C</name> <name>Example of MPLS Handoff with Option C</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="496" width="552" viewBox="0 0 552 496" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="496" width="552" viewBox="0 0 552 496" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,288 L 8,416" fill="none" stroke="black"/> <path d="M 8,288 L 8,416" fill="none" stroke="black"/>
<path d="M 24,320 L 24,384" fill="none" stroke="black"/> <path d="M 24,320 L 24,384" fill="none" stroke="black"/>
<path d="M 40,288 L 40,320" fill="none" stroke="black"/> <path d="M 40,288 L 40,320" fill="none" stroke="black"/>
<path d="M 48,384 L 48,416" fill="none" stroke="black"/> <path d="M 48,384 L 48,416" fill="none" stroke="black"/>
<path d="M 56,272 L 56,320" fill="none" stroke="black"/> <path d="M 56,272 L 56,320" fill="none" stroke="black"/>
<path d="M 72,320 L 72,384" fill="none" stroke="black"/> <path d="M 72,320 L 72,384" fill="none" stroke="black"/>
<path d="M 136,320 L 136,384" fill="none" stroke="black"/> <path d="M 136,320 L 136,384" fill="none" stroke="black"/>
<path d="M 152,288 L 152,320" fill="none" stroke="black"/> <path d="M 152,288 L 152,320" fill="none" stroke="black"/>
skipping to change at line 2740 skipping to change at line 3294
| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ | | +--+--+ +-+---+ +---+-+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 | | CS1| | Network | | L2/L3 CS2 |
+----+ +---------------+ +---------------------+ +----+ +---------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS label) # Service instances (with unique MPLS label)
* SDP * SDP
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!--[rfced] Please clarify "label swap forwarding entries" in this sentence.
Original:
Appropriate label swap forwarding entries
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
Perhaps:
Appropriate label swaps of forwarding entries
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
Or:
Appropriate forwarding entries for label swaps
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
-->
<t>This architecture requires an end-to-end Label Switched Path (LSP) leading from a packet's <t>This architecture requires an end-to-end Label Switched Path (LSP) leading from a packet's
ingress node inside one customer site to its egress inside another customer ingress node inside one customer site to its egress inside another customer
site, through a provider network. Hence, at the domain (customer site, provider site, through a provider network. Hence, at the domain (customer site and provid
network) er network)
boundaries NEXT_HOP attribute for IPv4/IPv6 labeled unicast needs to be modified boundaries, the NEXT_HOP attribute for IPv4/IPv6 labeled unicast needs to be mod
to "next-hop self" (nhs), ified to next-hop self (nhs),
which results in new IPv4/IPv6 labeled unicast label allocation. Appropriate lab which results in a new IPv4/IPv6 labeled unicast label allocation. Appropriate l
el swap abel swap
forwarding entries for IPv4/IPv6 labeled unicast labels are programmed in the da ta plane. forwarding entries for IPv4/IPv6 labeled unicast labels are programmed in the da ta plane.
There is no additional 'labeled transport' protocol on the AC (e.g., no LDP, RSV There is no additional "labeled transport" protocol on the AC (e.g., no LDP, RSV
P, or SR).</t> P, or SR).</t>
<t>Packets are transmitted over the AC with the IPv4/IPv6 labeled
unicast as the top label, with service label deeper in the label stack. In Optio <!-- [rfced] How does the text starting with "used as NEXT_HOP..." connect to
n C, the rest of the sentence?
Original:
This significantly lowers the scaling pressure on
PEs, as PEs need to program forwarding entries only for IPv4/IPv6
labeled unicast host routes, used as NEXT_HOP for service prefixes.
Perhaps:
This significantly lowers the scaling pressure on
PEs, as PEs need to program forwarding entries only for IPv4/IPv6
labeled unicast host routes, which are used as NEXT_HOP for service prefixes.
-->
<t>Packets are transmitted over the AC with the IPv4/IPv6 labeled
unicast as the top label, with the service label deeper in the label stack. In O
ption C,
the service label is not used for forwarding lookup on the PE. This significantl y the service label is not used for forwarding lookup on the PE. This significantl y
lowers the scaling pressure on PEs, as PEs need to program forwarding entries on ly for lowers the scaling pressure on PEs, as PEs need to program forwarding entries on ly for
IPv4/IPv6 labeled unicast host routes, used as NEXT_HOP for service prefixes. Al so, IPv4/IPv6 labeled unicast host routes, used as NEXT_HOP for service prefixes. Al so,
since one IPv4/IPv6 labeled unicast host route represent one customer site, rega rdless since one IPv4/IPv6 labeled unicast host route represents one customer site, reg ardless
of the number of slices in the customer site, the number of forwarding entries of the number of slices in the customer site, the number of forwarding entries
on a PE is considerably reduced.</t> on a PE is considerably reduced.</t>
<t>For any slice-specific per-hop behavior at the provider network edg e, as described <t>For any slice-specific per-hop behavior at the provider network edg e, as described
in details in <xref target="sec-over-rea-model"/>, the PE needs to determine whi ch label in the packet in detail in <xref target="sec-over-rea-model"/>, the PE needs to determine whic h label in the packet
represents which slice. This can be achieved, for example, by allocating non-ove rlapping service label represents which slice. This can be achieved, for example, by allocating non-ove rlapping service label
ranges for each slice, and use these ranges for slice identification purposes on PE.</t> ranges for each slice and using those ranges for slice identification purposes o n the PE.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-qos-map"> <section anchor="sec-qos-map">
<name>QoS Mapping Realization Models</name> <name>QoS Mapping Realization Models</name>
<section anchor="sec-qos-layers"> <section anchor="sec-qos-layers">
<name>QoS Layers</name> <name>QoS Layers</name>
<t>The resources are managed via various QoS policies deployed in the <t>The resources are managed via various QoS policies deployed in the
network. QoS mapping models to support 5G slicing connectivity network. QoS mapping models to support 5G slicing connectivity
implemented over packet switched provider network uses two layers of QoS that are discussed in <xref target="sec-qos-layers"/>.</t> implemented over a packet switched provider network use two layers of QoS, wh ich are discussed in the following subsections.</t>
<section anchor="g-qos-layer"> <section anchor="g-qos-layer">
<name>5G QoS Layer</name> <name>5G QoS Layer</name>
<t>QoS treatment is indicated in the 5G QoS layer by the 5G QoS <t>QoS treatment is indicated in the 5G QoS layer by the 5G QoS
Indicator (5QI), as defined in <xref target="TS-23.501"/>. A 5QI is an identi fier that is Indicator (5QI), as defined in <xref target="TS-23.501"/>. The 5QI is an iden tifier that is
used as a reference to 5G QoS characteristics (e.g., scheduling used as a reference to 5G QoS characteristics (e.g., scheduling
weights, admission thresholds, queue management thresholds, and link weights, admission thresholds, queue management thresholds, and link-layer pr
layer protocol configuration) in the RAN domain. Given that otocol configuration) in the RAN domain. Given that
5QI applies to the RAN domain, it is not visible to the 5QI applies to the RAN domain, it is not visible to the
provider network. Therefore, if 5QI-aware treatment is desired in the provid er provider network. Therefore, if 5QI-aware treatment is desired in the provid er
network as well, 5G network functions might set DSCP with a value network, 5G network functions might set DSCP with a value
representing 5QI so that differentiated treatment can be implemented in the p rovider network representing 5QI so that differentiated treatment can be implemented in the p rovider network
as well. Based on these DSCP values, at SDP of each provider network segment as well. Based on these DSCP values,
used to construct transport for given 5G slice, very granular QoS very granular QoS
enforcement might be implemented.</t> enforcement might be implemented at the SDP of each provider network segment
used to construct transport for given 5G slice.</t>
<t>The exact mapping between 5QI and <t>The exact mapping between 5QI and
DSCP is out of scope for this document. Mapping recommendations DSCP is out of scope for this document. Mapping recommendations
are documented, e.g., in <xref target="I-D.cbs-teas-5qi-to-dscp-mapping"/>.</ t> are documented, e.g., in <xref target="I-D.cbs-teas-5qi-to-dscp-mapping"/>.</ t>
<t>Each slice service might have flows with multiple 5QIs. 5QIs (or, m ore precisely, <t>Each slice service might have flows with multiple 5QIs. 5QIs (or, m ore precisely,
corresponding DSCP values) are visible to the provider network at SDPs corresponding DSCP values) are visible to the provider network at SDPs
(i.e., at the edge of the provider network).</t> (i.e., at the edge of the provider network).</t>
<t>In this document, this layer of QoS is referred to as '5G QoS <t>In this document, this layer of QoS is referred to as "5G QoS
Class' ('5G QoS' in short) or '5G DSCP'.</t> Class" ("5G QoS" in short) or "5G DSCP".</t>
</section> </section>
<section anchor="transport-network-tn-qos-layer"> <section anchor="transport-network-tn-qos-layer">
<name>Transport Network (TN) QoS Layer</name> <name>Transport Network (TN) QoS Layer</name>
<t>Control of the TN resources on provider network transit links, as w <t>Control of the TN resources and traffic
ell as traffic scheduling/prioritization on provider network transit links are based on a fl
scheduling/prioritization on provider network transit links, is based on a fl at
at
(non-hierarchical) QoS model in this Network Slice (non-hierarchical) QoS model in this Network Slice
realization. That is, RFC 9543 Network Slices are assigned dedicated realization. That is, RFC 9543 Network Slices are assigned dedicated
resources (e.g., QoS queues) at the edge of the provider network (at resources (e.g., QoS queues) at the edge of the provider network (at
SDPs), while all RFC 9543 Network Slices are sharing resources (sharing SDPs), while all RFC 9543 Network Slices are sharing resources (sharing
QoS queues) on the transit links of the provider network. Typical router QoS queues) on the transit links of the provider network. Typical router
hardware can support up to 8 traffic queues per port, therefore hardware can support up to 8 traffic queues per port; therefore,
the document assumes 8 traffic queues per port support in this document assumes support for 8 traffic queues per port in
general.</t> general.</t>
<t>At this layer, QoS treatment is indicated by a QoS indicator <t>At this layer, QoS treatment is indicated by a QoS indicator
specific to the encapsulation used in the provider network. Such an indicator may specific to the encapsulation used in the provider network. Such an indicator may
be DSCP or MPLS Traffic Class (TC). This layer of QoS is referred to as 'TN Q be a DSCP or MPLS Traffic Class (TC). This layer of QoS is referred to as "TN
oS QoS
Class', or 'TN QoS' for short, in this document.</t> Class" ("TN QoS" for short) in this document.</t>
</section> </section>
</section> </section>
<section anchor="qos-realization-models"> <section anchor="qos-realization-models">
<name>QoS Realization Models</name> <name>QoS Realization Models</name>
<t>While 5QI might be exposed to the provider network via the DSCP value <t>While 5QI might be exposed to the provider network via the DSCP value
(corresponding to specific 5QI value) set in the IP packet generated (corresponding to a specific 5QI value) set in the IP packet generated
by NFs, some 5G deployments might use 5QI in the RAN domain only, by NFs, some 5G deployments might use 5QI in the RAN domain only,
without requesting per-5QI differentiated treatment from the provider network . without requesting per-5QI differentiated treatment from the provider network .
This might be due to an NF limitation (e.g., no capability to set This might be due to an NF limitation (e.g., no capability to set
DSCP), or it might simply depend on the overall slicing deployment DSCP), or it might simply depend on the overall slicing deployment
model. The O-RAN Alliance, for example, defines a phased approach to model. The O-RAN Alliance, for example, defines a phased approach to
the slicing, with initial phases utilizing only per-slice, but not the slicing, with initial phases utilizing only per-slice, but not
per-5QI, differentiated treatment in the TN domain per-5QI, differentiated treatment in the TN domain
(Annex F of <xref target="O-RAN.WG9.XPSAAS"/>).</t> (see Annex F of <xref target="O-RAN.WG9.XPSAAS"/>).</t>
<t>Therefore, from a QoS perspective, the 5G slicing connectivity <t>Therefore, from a QoS perspective, the 5G slicing connectivity
realization defines two high-level realization models realization defines two high-level realization models
for slicing in the TN domain: a 5QI-unaware model and a 5QI- for slicing in the TN domain: a 5QI-unaware model and a 5QI-aware model. Bot
aware model. Both slicing models in the TN domain could be h slicing models in the TN domain could be
used concurrently within the same 5G slice. For example, the TN used concurrently within the same 5G slice. For example, the TN
segment for 5G midhaul (F1-U interface) might be 5QI-aware, while segment for 5G midhaul (F1-U interface) might be 5QI-aware, while
at the same time the TN segment for 5G backhaul (N3 interface) might at the same time, the TN segment for 5G backhaul (N3 interface) might
follow the 5QI-unaware model.</t> follow the 5QI-unaware model.</t>
<t>These models are further elaborated in the following two subsections. </t> <t>These models are further elaborated in the following two subsections. </t>
<section anchor="sec-5QI-unaware"> <section anchor="sec-5QI-unaware">
<name>5QI-unaware Model</name> <name>5QI-Unaware Model</name>
<t>In 5QI-unaware mode, the DSCP values in the packets received from N
F <t>In the 5QI-unaware model, the DSCP values in the packets received f
rom NF
at SDP are ignored. In the provider network, there is no QoS at SDP are ignored. In the provider network, there is no QoS
differentiation at the 5G QoS Class level. The entire RFC 9543 Network differentiation at the 5G QoS Class level. The entire RFC 9543 Network
Slice is mapped to a single TN QoS Class, and, therefore, to a single Slice is mapped to a single TN QoS Class and therefore to a single
QoS queue on the routers in the provider network. With a few number of QoS queue on the routers in the provider network. With a low number of
deployed 5G slices (for example, only two 5G slices: eMBB and MIoT), deployed 5G slices (for example, only two 5G slices: eMBB and MIoT),
it is possible to dedicate a separate QoS queue for each slice on it is possible to dedicate a separate QoS queue for each slice on
transit routers in the provider network. However, with the introduction of p rivate/enterprises transit routers in the provider network. However, with the introduction of p rivate/enterprises
slices, as the number of 5G slices (and thus corresponding RFC 9543 slices, as the number of 5G slices (and thus the corresponding RFC 9543
Network Slices) increases, a single QoS queue on transit links in the provide r network serves Network Slices) increases, a single QoS queue on transit links in the provide r network serves
multiple slices with similar characteristics. QoS enforcement on multiple slices with similar characteristics. QoS enforcement on
transit links is fully coarse-grained (single NRP, sharing resources among transit links is fully coarse-grained (single NRP, sharing resources among
all RFC 9543 Network Slices), as displayed in <xref target="_figure-QoS-5QI-u naware"/>.</t> all RFC 9543 Network Slices), as displayed in <xref target="_figure-QoS-5QI-u naware"/>.</t>
<figure anchor="_figure-QoS-5QI-unaware"> <figure anchor="_figure-QoS-5QI-unaware">
<name>Slice to TN QoS Mapping (5QI-unaware Model)</name> <name>Mapping of Slice to TN QoS (5QI-Unaware Model)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="624" width="560" viewBox="0 0 560 624" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="624" width="560" viewBox="0 0 560 624" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,32 L 8,560" fill="none" stroke="black"/> <path d="M 8,32 L 8,560" fill="none" stroke="black"/>
<path d="M 24,80 L 24,144" fill="none" stroke="black"/> <path d="M 24,80 L 24,144" fill="none" stroke="black"/>
<path d="M 24,176 L 24,240" fill="none" stroke="black"/> <path d="M 24,176 L 24,240" fill="none" stroke="black"/>
<path d="M 24,272 L 24,336" fill="none" stroke="black"/> <path d="M 24,272 L 24,336" fill="none" stroke="black"/>
<path d="M 24,368 L 24,432" fill="none" stroke="black"/> <path d="M 24,368 L 24,432" fill="none" stroke="black"/>
<path d="M 24,464 L 24,528" fill="none" stroke="black"/> <path d="M 24,464 L 24,528" fill="none" stroke="black"/>
<path d="M 48,96 L 48,128" fill="none" stroke="black"/> <path d="M 48,96 L 48,128" fill="none" stroke="black"/>
<path d="M 48,192 L 48,224" fill="none" stroke="black"/> <path d="M 48,192 L 48,224" fill="none" stroke="black"/>
skipping to change at line 3106 skipping to change at line 3691
| '--------------' | | | '--------------' | |
+-------------------' | +-------------------' |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
Fine-grained QoS enforcement Coarse-grained QoS enforcement Fine-grained QoS enforcement Coarse-grained QoS enforcement
(dedicated resources per (resources shared by multiple (dedicated resources per (resources shared by multiple
RFC 9543 Network Slice) RFC 9543 Network Slices) RFC 9543 Network Slice) RFC 9543 Network Slices)
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>When the IP traffic is handed over at the SDP from the AC to the pr ovider network, the PE encapsulates the <t>When the IP traffic is handed over at the SDP from the AC to the pr ovider network, the PE encapsulates the
traffic into MPLS (if MPLS transport is used in the provider network), or traffic into MPLS (if MPLS transport is used in the provider network) or
IPv6 - optionally with some additional headers (if SRv6 transport is IPv6, optionally with some additional headers (if SRv6 transport is
used in the provider network), and sends out the packets on the provider netw ork transit used in the provider network), and sends out the packets on the provider netw ork transit
link.</t> link.</t>
<t>The original IP header retains the DCSP marking (which is ignored i
n <!-- [rfced] The sentence below uses "SRv6 encapsulation" while the title of
5QI-unaware model), while the new header (MPLS or IPv6) carries QoS Figure 19 uses "IPv6 Encapsulation". Should these be consistent? If so,
marking (MPLS Traffic Class bits for MPLS encapsulation, or DSCP for which form should be used?
SRv6/IPv6 encapsulation) related to TN Class of Service (CoS). Based on TN C
oS Original:
This model is outlined in Figure 18 for MPLS
encapsulation, and in Figure 19 for SRv6 encapsulation.
...
Figure 19: QoS with IPv6 Encapsulation
-->
<t>The original IP header retains the DSCP marking (which is ignored i
n the
5QI-unaware model), while the new header (MPLS or IPv6) carries the QoS
marking (MPLS Traffic Class bits for MPLS encapsulation or DSCP for
SRv6/IPv6 encapsulation) related to the TN Class of Service (CoS). Based on
the TN CoS
marking, per-hop behavior for all RFC 9543 Network Slices is executed on marking, per-hop behavior for all RFC 9543 Network Slices is executed on
provider network transit links. Provider network transit routers do not eval uate the original IP provider network transit links. Provider network transit routers do not eval uate the original IP
header for QoS-related decisions. This model is outlined in header for QoS-related decisions. This model is outlined in
<xref target="_figure-15"/> for MPLS encapsulation, and in <xref target="_fig ure-16"/> for SRv6 <xref target="_figure-15"/> for MPLS encapsulation and in <xref target="_figu re-16"/> for SRv6
encapsulation.</t> encapsulation.</t>
<figure anchor="_figure-15"> <figure anchor="_figure-15">
<name>QoS with MPLS Encapsulation</name> <name>QoS with MPLS Encapsulation</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="336" width="400" viewBox="0 0 400 336" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="336" width="400" viewBox="0 0 400 336" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,96 L 8,320" fill="none" stroke="black"/> <path d="M 8,96 L 8,320" fill="none" stroke="black"/>
<path d="M 64,128 L 64,160" fill="none" stroke="black"/> <path d="M 64,128 L 64,160" fill="none" stroke="black"/>
<path d="M 128,96 L 128,320" fill="none" stroke="black"/> <path d="M 128,96 L 128,320" fill="none" stroke="black"/>
<path d="M 208,104 L 208,144" fill="none" stroke="black"/> <path d="M 208,104 L 208,144" fill="none" stroke="black"/>
<path d="M 208,272 L 208,312" fill="none" stroke="black"/> <path d="M 208,272 L 208,312" fill="none" stroke="black"/>
skipping to change at line 3313 skipping to change at line 3910
| | | / | | | | | / | |
| | |/ | | | | |/ | |
+--------------+ - - - - - - - - +--------------+ +--------------+ - - - - - - - - +--------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>From a QoS perspective, both options are similar. However, there <t>From a QoS perspective, both options are similar. However, there
is one difference between the two options. The MPLS TC is only 3 is one difference between the two options. The MPLS TC is only 3
bits (8 possible combinations), while DSCP is 6 bits (64 possible bits (8 possible combinations), while DSCP is 6 bits (64 possible
combinations). Hence, SRv6 provides more flexibility for TN CoS combinations). Hence, SRv6 provides more flexibility for TN CoS
design, especially in combination with soft policing with in-profile/ design, especially in combination with soft policing with in-profile and
out-profile traffic, as discussed in <xref target="sec-inbound-edge-resource- out-of-profile traffic, as discussed in <xref target="sec-inbound-edge-resour
control"/>.</t> ce-control"/>.</t>
<t>Provider network edge resources are controlled in a granular, fine- <t>Provider network edge resources are controlled in a fine-grained
grained
manner, with dedicated resource allocation for each RFC 9543 Network manner, with dedicated resource allocation for each RFC 9543 Network
Slice. The resource control/enforcement happens at each SDP in two Slice. Resource control and enforcement happens at each SDP in two
directions: inbound and outbound.</t> directions: inbound and outbound.</t>
<section anchor="sec-inbound-edge-resource-control"> <section anchor="sec-inbound-edge-resource-control">
<name>Inbound Edge Resource Control</name> <name>Inbound Edge Resource Control</name>
<t>The main aspect of inbound provider network edge resource control is per-slice traffic <t>The main aspect of inbound provider network edge resource control is per-slice traffic
volume enforcement. This kind of enforcement is often called volume enforcement. This kind of enforcement is often called
'admission control' or 'traffic conditioning'. The goal of this "admission control" or "traffic conditioning". The goal of this
inbound enforcement is to ensure that the traffic above the inbound enforcement is to ensure that the traffic above the
contracted rate is dropped or deprioritized, depending on the contracted rate is dropped or deprioritized, depending on the
business rules, right at the edge of provider network. This, combined with business rules, right at the edge of provider network. This, combined with
appropriate network capacity planning/management (<xref target="sec-capacity- planning"/>) is required to ensure proper isolation between slices in appropriate network capacity planning/management (<xref target="sec-capacity- planning"/>), is required to ensure proper isolation between slices in
a scalable manner. As a result, traffic of one slice has no influence a scalable manner. As a result, traffic of one slice has no influence
on the traffic of other slices, even if the slice is misbehaving on the traffic of other slices, even if the slice is misbehaving
(e.g., Distributed Denial-of-Service (DDoS) attacks or node/link failures) an d generates traffic (e.g., Distributed Denial-of-Service (DDoS) attacks or node/link failures) an d generates traffic
volumes above the contracted rates.</t> volumes above the contracted rates.</t>
<t>The slice rates can be characterized with following parameters
<!-- [rfced] Is the citation [I-D.ietf-teas-ietf-network-slice-nbi-yang]
correct here? We ask because we do not see "slice rate", "CIR", or "PIR"
in that document.
Link to document:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
Original:
The slice rates can be characterized with following parameters
[I-D.ietf-teas-ietf-network-slice-nbi-yang]:
* CIR: Committed Information Rate (i.e., guaranteed bandwidth)
* PIR: Peak Information Rate (i.e., maximum bandwidth)
-->
<t>The slice rates can be characterized with the following parameters
<xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>:</t> <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>CIR: Committed Information Rate (i.e., guaranteed bandwidth)< CIR: Committed Information Rate (i.e., guaranteed bandwidth)</li
/t> >
</li> <li>
<li> PIR: Peak Information Rate (i.e., maximum bandwidth)</li>
<t>PIR: Peak Information Rate (i.e., maximum bandwidth)</t>
</li>
</ul> </ul>
<t>These parameters define the traffic characteristics of the slice and <t>These parameters define the traffic characteristics of the slice and
are part of SLO parameter set provided by the 5G NSO to an NSC. Based are part of the SLO parameter set provided by the 5G NSO to an NSC. Based
on these parameters, the provider network's inbound policy can be implemented using one on these parameters, the provider network's inbound policy can be implemented using one
of following options:</t> of following options:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>1r2c (single-rate two-color) rate limiter </t> <t>1r2c (single-rate two-color) rate limiter </t>
<!-- [rfced] Please confirm that Section 2.3 of [RFC2475] is correct here. We
do not see "1r2c", "color", or "single rate" in [RFC2475].
Original:
* 1r2c (single-rate two-color) rate limiter
This is the most basic rate limiter, described in Section 2.3 of
[RFC2475].
-->
<t> <t>
This is the most basic rate limiter, described in <xref section="2.3" sectionFor mat="of" target="RFC2475"/>. This is the most basic rate limiter, described in <xref section="2.3" sectionFor mat="of" target="RFC2475"/>.
It meters at the SDP a At the SDP, it meters a
traffic stream of given slice and marks its packets as in-profile traffic stream of a given slice and marks its packets as in-profile
(below CIR being enforced) or out-of-profile (above CIR being enforced). (below CIR being enforced) or out-of-profile (above CIR being enforced).
In-profile packets are accepted and forwarded. Out-of profile In-profile packets are accepted and forwarded. Out-of-profile
packets are either dropped right at the SDP (hard rate limiting), packets are either dropped right at the SDP (hard rate limiting)
or remarked (with different MPLS TC or DSCP TN markings) to or re-marked (with different MPLS TC or DSCP TN markings) to
signify 'this packet should be dropped in the first place, if signify "this packet should be dropped in the first place, if
there is a congestion' (soft rate limiting), depending on the there is congestion" (soft rate limiting), depending on the
business policy of the provider network. In the second case, while business policy of the provider network. In the latter case, while
packets above CIR are forwarded at the SDP, they are subject to being packets above CIR are forwarded at the SDP, they are subject to being
dropped during any congestion event at any place in the provider network.</t> dropped during any congestion event at any place in the provider network.</t>
</li> </li>
<li> <li>
<t>2r3c (two-rate three-color) rate limiter </t> <t>2r3c (two-rate three-color) rate limiter </t>
<t> <t>
This was initially defined in <xref target="RFC2698"/>, and its improved version This was initially defined in <xref target="RFC2698"/>, and an improved version
in <xref target="RFC4115"/>. In essence, the traffic is assigned to one of the is defined in <xref target="RFC4115"/>. In essence, the traffic is assigned to
these three one of the these three
categories: </t> categories: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Green, for traffic under CIR</t> <t>Green, for traffic under CIR</t>
</li> </li>
<li> <li>
<t>Yellow, for traffic between CIR and PIR</t> <t>Yellow, for traffic between CIR and PIR</t>
</li> </li>
<li> <li>
<t>Red, for traffic above PIR</t> <t>Red, for traffic above PIR</t>
</li> </li>
</ul> </ul>
<t> <t>
An inbound 2r3c meter implemented with <xref target="RFC4115"/>, compared to An inbound 2r3c meter implemented with <xref target="RFC4115"/>, compared to
<xref target="RFC2698"/>, is more 'customer friendly' as it doesn't impose <xref target="RFC2698"/>, is more "customer friendly" as it doesn't impose
outbound peak-rate shaping requirements on customer edge (CE) outbound peak-rate shaping requirements on CE
devices. 2r3c meters in general give greater flexibility for provider network ed devices. In general, 2r3c meters give greater flexibility for provider network e
ge dge
enforcement regarding accepting the traffic (green), enforcement regarding accepting the traffic (green),
de-prioritizing and potentially dropping the traffic on transit during deprioritizing and potentially dropping the traffic on transit during
congestion (yellow), or hard dropping the traffic (red).</t> congestion (yellow), or hard-dropping the traffic (red).</t>
</li> </li>
</ul> </ul>
<t>Inbound provider network edge enforcement model for 5QI-unaware m <!-- [rfced] We updated "provider" to "provider network" in the parenthetical
odel, where all packets in this sentence. Let us know if this is incorrect.
Original:
Inbound provider network edge enforcement model for 5QI-unaware
model, where all packets belonging to the slice are treated the same
way in the provider network (no 5Q QoS Class differentiation in the
provider) is outlined in Figure 20.
Perhaps:
Inbound provider network edge enforcement for the 5QI-unaware
model, where all packets belonging to the slice are treated the same
way in the provider network (no 5Q QoS Class differentiation in the
provider network), is outlined in Figure 20.
-->
<t>Inbound provider network edge enforcement for the 5QI-unaware mod
el, where all packets
belonging to the slice are treated the same way in the provider network (no belonging to the slice are treated the same way in the provider network (no
5Q QoS Class differentiation in the provider) is outlined in 5Q QoS Class differentiation in the provider), is outlined in
<xref target="_figure-17"/>.</t> <xref target="_figure-17"/>.</t>
<figure anchor="_figure-17"> <figure anchor="_figure-17">
<name>Ingress Slice Admission Control (5QI-unaware Model)</name> <name>Ingress Slice Admission Control (5QI-Unaware Model)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="576" width="280" viewBox="0 0 280 576" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="576" width="280" viewBox="0 0 280 576" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 120,64 L 120,128" fill="none" stroke="black"/> <path d="M 120,64 L 120,128" fill="none" stroke="black"/>
<path d="M 160,64 L 160,208" fill="none" stroke="black"/> <path d="M 160,64 L 160,208" fill="none" stroke="black"/>
<path d="M 160,240 L 160,368" fill="none" stroke="black"/> <path d="M 160,240 L 160,368" fill="none" stroke="black"/>
<path d="M 160,400 L 160,544" fill="none" stroke="black"/> <path d="M 160,400 L 160,544" fill="none" stroke="black"/>
<path d="M 192,48 L 192,64" fill="none" stroke="black"/> <path d="M 192,48 L 192,64" fill="none" stroke="black"/>
<path d="M 192,544 L 192,560" fill="none" stroke="black"/> <path d="M 192,544 L 192,560" fill="none" stroke="black"/>
<path d="M 216,64 L 216,208" fill="none" stroke="black"/> <path d="M 216,64 L 216,208" fill="none" stroke="black"/>
<path d="M 216,240 L 216,368" fill="none" stroke="black"/> <path d="M 216,240 L 216,368" fill="none" stroke="black"/>
skipping to change at line 3522 skipping to change at line 4162
<section anchor="outbound-edge-resource-control"> <section anchor="outbound-edge-resource-control">
<name>Outbound Edge Resource Control</name> <name>Outbound Edge Resource Control</name>
<t>While inbound slice admission control at the provider network edg e is <t>While inbound slice admission control at the provider network edg e is
mandatory in the architecture described in this document, outbound provider n etwork edge resource control might not be mandatory in the architecture described in this document, outbound provider n etwork edge resource control might not be
required in all use cases. Use cases that specifically call for required in all use cases. Use cases that specifically call for
outbound provider network edge resource control are:</t> outbound provider network edge resource control are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Slices use both CIR and PIR parameters, and provider network edge links <t>Slices use both CIR and PIR parameters, and provider network edge links
(ACs) are dimensioned to fulfill the aggregate of (ACs) are dimensioned to fulfill the aggregate of
slice CIRs. If at any given time, some slices send the traffic slice CIRs. If, at any given time, some slices send the traffic
above CIR, congestion in outbound direction on the provider network edge above CIR, congestion in the outbound direction on the provider network edge
link (AC) might happen. Therefore, fine-grained resource control to link (AC) might happen. Therefore, fine-grained resource control to
guarantee at least CIR for each slice is required.</t> guarantee at least CIR for each slice is required.</t>
</li> </li>
<li> <li>
<t>Any-to-Any (A2A) connectivity constructs are deployed, again <t>Any-to-Any (A2A) connectivity constructs are deployed, again
resulting in potential congestion in outbound direction on the resulting in potential congestion in the outbound direction on the
provider network edge links, even if only slice CIR parameters are used. provider network edge links, even if only slice CIR parameters are used.
This again requires fine-grained resource control per slice in This again requires fine-grained resource control per slice in
outbound direction at the provider network edge links.</t> the outbound direction at the provider network edge links.</t>
</li> </li>
</ul> </ul>
<t>As opposed to inbound provider network edge resource control, typ ically implemented <t>As opposed to inbound provider network edge resource control, typ ically implemented
with rate-limiters/policers, outbound resource control is typically with rate-limiters/policers, outbound resource control is typically
implemented with a weighted/priority queuing, potentially combined implemented with a weighted/priority queuing, potentially combined
with optional shapers (per slice). A detailed analysis of different with optional shapers (per slice). A detailed analysis of different
queuing mechanisms is out of scope for this document, but is provided queuing mechanisms is out of scope for this document but is provided
in <xref target="RFC7806"/>.</t> in <xref target="RFC7806"/>.</t>
<t><xref target="_figure-18"/> outlines the outbound provider networ k edge resource control model <t><xref target="_figure-18"/> outlines the outbound provider networ k edge resource control model
for 5QI-unaware slices. Each slice is for 5QI-unaware slices. Each slice is
assigned a single egress queue. The sum of slice CIRs, used as the assigned a single egress queue. The sum of slice CIRs, used as the
weight in weighted queueing model, should not exceed the physical weight in weighted queueing model, should not exceed the physical
capacity of the AC. Slice requests above this limit capacity of the AC. Slice requests above this limit
should be rejected by the NSC, unless an already established slice with should be rejected by the NSC, unless an already-established slice with
lower priority, if such exists, is preempted.</t> lower priority, if such exists, is preempted.</t>
<figure anchor="_figure-18"> <figure anchor="_figure-18">
<name>Ingress Slice Admission control (5QI-unaware Model) - Output </name> <name>Ingress Slice Admission Control (5QI-Unaware Model) - Output </name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="512" width="552" viewBox="0 0 552 512" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="512" width="552" viewBox="0 0 552 512" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 32,32 L 32,480" fill="none" stroke="black"/> <path d="M 32,32 L 32,480" fill="none" stroke="black"/>
<path d="M 80,64 L 80,176" fill="none" stroke="black"/> <path d="M 80,64 L 80,176" fill="none" stroke="black"/>
<path d="M 80,208 L 80,304" fill="none" stroke="black"/> <path d="M 80,208 L 80,304" fill="none" stroke="black"/>
<path d="M 80,336 L 80,448" fill="none" stroke="black"/> <path d="M 80,336 L 80,448" fill="none" stroke="black"/>
<path d="M 112,32 L 112,56" fill="none" stroke="black"/> <path d="M 112,32 L 112,56" fill="none" stroke="black"/>
<path d="M 112,456 L 112,480" fill="none" stroke="black"/> <path d="M 112,456 L 112,480" fill="none" stroke="black"/>
<path d="M 144,64 L 144,144" fill="none" stroke="black"/> <path d="M 144,64 L 144,144" fill="none" stroke="black"/>
<path d="M 144,200 L 144,272" fill="none" stroke="black"/> <path d="M 144,200 L 144,272" fill="none" stroke="black"/>
skipping to change at line 3774 skipping to change at line 4414
<text x="464" y="452">-</text> <text x="464" y="452">-</text>
<text x="480" y="452">-</text> <text x="480" y="452">-</text>
<text x="496" y="452">-</text> <text x="496" y="452">-</text>
<text x="512" y="452">-</text> <text x="512" y="452">-</text>
<text x="528" y="452">-</text> <text x="528" y="452">-</text>
<text x="544" y="452">-</text> <text x="544" y="452">-</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+---------+ QoS output queues +---------+ QoS output queues
| | | |
| +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| | S | \|/ | | S | \|/
| | l | | | | l | |
| | i | | | | i | |
| A | c | | weight-Slice-1-CIR | A | c | | weight-Slice-1-CIR
| t | e .--|--------------------------. | shaping-Slice-1-PIR | t | e .--|--------------------------. | shaping-Slice-1-PIR
---|--t--|---|--> | | ---|--t--|---|--> | |
| a | 1 '--|--------------------------' /|\ | a | 1 '--|--------------------------' /|\
| c ------ - - - - - - - - - - - - - - - - - - - - - - - - - - | c ------ - - - - - - - - - - - - - - - - - - - - - - - - - -
| h | S | \|/ | h | S | \|/
| m | l | | | m | l | |
| e | i | | | e | i | |
| n | c | | weight-Slice-2-CIR | n | c | | weight-Slice-2-CIR
| t | e .--|--------------------------. | shaping-Slice-2-PIR | t | e .--|--------------------------. | shaping-Slice-2-PIR
---|-----|---|--> | | ---|-----|---|--> | |
| C | 2 '--|--------------------------' /|\ | C | 2 '--|--------------------------' /|\
| i ------ - - - - - - - - - - - - - - - - - - - - - - - - - - | i ------ - - - - - - - - - - - - - - - - - - - - - - - - - -
| r | S | \|/ | r | S | \|/
| c | l | | | c | l | |
| u | i | | | u | i | |
| i | c | | weight-Slice-3-CIR | i | c | | weight-Slice-3-CIR
| t | e .--|--------------------------. | shaping-Slice-3-PIR | t | e .--|--------------------------. | shaping-Slice-3-PIR
---|-----|---|--> | | ---|-----|---|--> | |
| | 3 '--|--------------------------' /|\ | | 3 '--|--------------------------' /|\
| +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
+---------+ +---------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="qi-aware-model"> <section anchor="qi-aware-model">
<name>5QI-aware Model</name> <name>5QI-Aware Model</name>
<t>In the 5QI-aware model, potentially a large number of 5G QoS Classe <t>In the 5QI-aware model, a potentially large number of 5G QoS Classe
s, represented via the DSCP set by NFs s, represented via the DSCP set by NFs
(the architecture scales to thousands of 5G slices) is mapped (the architecture scales to thousands of 5G slices), is mapped
(multiplexed) to up to 8 TN QoS Classes used in a provider network transit (multiplexed) to up to 8 TN QoS Classes used in a provider network transit
equipment, as outlined in <xref target="_figure-QoS-5QI-aware"/>.</t> equipment, as outlined in <xref target="_figure-QoS-5QI-aware"/>.</t>
<figure anchor="_figure-QoS-5QI-aware"> <figure anchor="_figure-QoS-5QI-aware">
<name>Slice 5Q QoS to TN QoS Mapping (5QI-aware Model)</name> <name>Mapping of Slice 5Q QoS to TN QoS (5QI-Aware Model)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="624" width="584" viewBox="0 0 584 624" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="624" width="584" viewBox="0 0 584 624" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 24,32 L 24,560" fill="none" stroke="black"/> <path d="M 24,32 L 24,560" fill="none" stroke="black"/>
<path d="M 40,80 L 40,288" fill="none" stroke="black"/> <path d="M 40,80 L 40,288" fill="none" stroke="black"/>
<path d="M 40,320 L 40,528" fill="none" stroke="black"/> <path d="M 40,320 L 40,528" fill="none" stroke="black"/>
<path d="M 168,64 L 168,104" fill="none" stroke="black"/> <path d="M 168,64 L 168,104" fill="none" stroke="black"/>
<path d="M 168,120 L 168,152" fill="none" stroke="black"/> <path d="M 168,120 L 168,152" fill="none" stroke="black"/>
<path d="M 168,168 L 168,200" fill="none" stroke="black"/> <path d="M 168,168 L 168,200" fill="none" stroke="black"/>
<path d="M 168,216 L 168,248" fill="none" stroke="black"/> <path d="M 168,216 L 168,248" fill="none" stroke="black"/>
<path d="M 168,304 L 168,328" fill="none" stroke="black"/> <path d="M 168,304 L 168,328" fill="none" stroke="black"/>
skipping to change at line 4148 skipping to change at line 4788
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Fine-grained QoS enforcement Coarse-grained QoS enforcement Fine-grained QoS enforcement Coarse-grained QoS enforcement
(dedicated resources per (resources shared by multiple (dedicated resources per (resources shared by multiple
RFC 9543 Network Slice) RFC 9543 Network Slices) RFC 9543 Network Slice) RFC 9543 Network Slices)
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Given that in deployments with a large number of 5G <t>Given that in deployments with a large number of 5G
slices, the number of potential 5G QoS Classes is much higher than slices, the number of potential 5G QoS Classes is much higher than
the number of TN QoS Classes, multiple 5G QoS Classes with similar the number of TN QoS Classes, multiple 5G QoS Classes with similar
characteristics - potentially from different slices - characteristics -- potentially from different slices --
would be grouped with common operator-defined TN logic and mapped to a same T would be grouped with common operator-defined TN logic and mapped to the same
N QoS Class when transported in the TN QoS Class when transported in the
provider network. That is, common Per-hop Behavior (PHB) <xref target="RFC24 provider network. That is, common Per-Hop Behavior (PHB) <xref target="RFC24
74"/> is executed on 74"/> is executed on
transit provider network routers for all packets grouped together. An example of this transit provider network routers for all packets grouped together. An example of this
approach is outlined in <xref target="_figure-QoS-5QI-mapping-example"/>. A p rovider may decide approach is outlined in <xref target="_figure-QoS-5QI-mapping-example"/>. A p rovider may decide
to implement Diffserv-Intercon PHBs at the boundaries of its network domain < xref target="RFC8100"/>.</t> to implement Diffserv-Intercon PHBs at the boundaries of its network domain < xref target="RFC8100"/>.</t>
<dl>
<dt>Note:</dt> <aside>
<dd> <t>Note: The numbers indicated in <xref
<t>The numbers indicated in <xref target="_figure-QoS-5QI-mapping- target="_figure-QoS-5QI-mapping-example"/> (S-NSSAI, 5QI, DSCP, queue,
example"/> (S-NSSAI, 5QI, DSCP, queue, etc.) are provided for illustration purpo etc.) are provided for illustration purposes only and should not be
ses only and should not be considered as deployment guidance.</t> considered as deployment guidance.</t>
</dd> </aside>
</dl>
<figure anchor="_figure-QoS-5QI-mapping-example"> <figure anchor="_figure-QoS-5QI-mapping-example">
<name>Example of 3GPP QoS Mapped to TN QoS</name> <name>Example of 3GPP QoS Mapped to TN QoS</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="512" width="520" viewBox="0 0 520 512" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="512" width="520" viewBox="0 0 520 512" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,48 L 8,80" fill="none" stroke="black"/> <path d="M 8,48 L 8,80" fill="none" stroke="black"/>
<path d="M 8,112 L 8,240" fill="none" stroke="black"/> <path d="M 8,112 L 8,240" fill="none" stroke="black"/>
<path d="M 8,272 L 8,464" fill="none" stroke="black"/> <path d="M 8,272 L 8,464" fill="none" stroke="black"/>
<path d="M 184,48 L 184,104" fill="none" stroke="black"/> <path d="M 184,48 L 184,104" fill="none" stroke="black"/>
<path d="M 184,120 L 184,152" fill="none" stroke="black"/> <path d="M 184,120 L 184,152" fill="none" stroke="black"/>
<path d="M 184,168 L 184,200" fill="none" stroke="black"/> <path d="M 184,168 L 184,200" fill="none" stroke="black"/>
skipping to change at line 4421 skipping to change at line 5063
| .------. .-------. | | | .-------. | | | | .------. .-------. | | | .-------. | | |
| |5QI=7 +->DSCP=10 +------>DSCP=10 +-----+ | | |5QI=7 +->DSCP=10 +------>DSCP=10 +-----+ |
| '------' '-------' | | | '-------' | | | '------' '-------' | | | '-------' | |
+---------------------+ | '----------' | +---------------------+ | '----------' |
+--------------------------------------+ +--------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In current SDO progress of 3GPP (Release 17) and O-RAN, the mapping of 5QI to <t>In current SDO progress of 3GPP (Release 17) and O-RAN, the mapping of 5QI to
DSCP is not expected to be in a per-slice fashion, where 5QI to DSCP mapping may DSCP is not expected to be in a per-slice fashion, where 5QI-to-DSCP mapping may
vary from 3GPP slice to 3GPP slice, hence the mapping of 5G QoS DSCP values vary from 3GPP slice to 3GPP slice; hence, the mapping of 5G QoS DSCP values
to TN QoS Classes may be rather common.</t> to TN QoS Classes may be rather common.</t>
<t>Like in the 5QI-unaware model, the original IP header retains the D CSP <t>Like in the 5QI-unaware model, the original IP header retains the D SCP
marking corresponding to 5QI (5G QoS Class), while the new header marking corresponding to 5QI (5G QoS Class), while the new header
(MPLS or IPv6) carries QoS marking related to TN QoS Class. Based on (MPLS or IPv6) carries the QoS marking related to TN QoS Class. Based on
TN QoS Class marking, per-hop behavior for all aggregated 5G QoS the TN QoS Class marking, per-hop behavior for all aggregated 5G QoS
Classes from all RFC 9543 Network Slices is executed on the provider network transit links. Provider network Classes from all RFC 9543 Network Slices is executed on the provider network transit links. Provider network
transit routers do not evaluate the original IP header for QoS transit routers do not evaluate the original IP header for QoS-related decisi
related decisions. The original DSCP marking retained in the ons. The original DSCP marking retained in the
original IP header is used at the PE for fine-grained per slice and original IP header is used at the PE for fine-grained inbound/outbound enforc
per 5G QoS Class inbound/outbound enforcement on the AC.</t> ement per slice and
<t>In the 5QI-aware model, compared to the 5QI-unaware model, provider per 5G QoS Class on the AC.</t>
network edge resources are controlled in an even more
<!-- [rfced] Please clarify "most commonly up 4 or 8 traffic classes".
(Also, we suggest removing "granular" as it's redundant with "fine-grained".)
Original:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more granular, fine-
grained manner, with dedicated resource allocation for each RFC 9543
Network Slice and dedicated resource allocation for number of traffic
classes (most commonly up 4 or 8 traffic classes, depending on the
Hardware capability of the equipment) within each RFC 9543 Network
Slice.
Perhaps:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more fine-grained
manner, with dedicated resource allocation for each RFC 9543
Network Slice and for a number of traffic
classes (most commonly, 4 or 8 traffic classes, depending on the
hardware capability of the equipment) within each RFC 9543 Network
Slice.
Or:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more fine-grained
manner, with dedicated resource allocation for each RFC 9543
Network Slice and for a number of traffic
classes (most commonly, up to 4 or 8 traffic classes, depending on the
hardware capability of the equipment) within each RFC 9543 Network
Slice.
-->
<t>In the 5QI-aware model, compared to the 5QI-unaware model, provider networ
k edge resources are controlled in an even more
granular, fine-grained manner, with dedicated resource allocation for granular, fine-grained manner, with dedicated resource allocation for
each RFC 9543 Network Slice and dedicated resource allocation for number each RFC 9543 Network Slice and for a number
of traffic classes (most commonly up 4 or 8 traffic classes, of traffic classes (most commonly up 4 or 8 traffic classes,
depending on the Hardware capability of the equipment) within each RFC 9543 depending on the hardware capability of the equipment) within each RFC 9543
Network Slice.</t> Network Slice.</t>
<section anchor="inbound-edge-resource-control"> <section anchor="inbound-edge-resource-control">
<name>Inbound Edge Resource Control</name> <name>Inbound Edge Resource Control</name>
<t>Compared to the 5QI-unaware model, admission control (traffic <t>Compared to the 5QI-unaware model, admission control (traffic
conditioning) in the 5QI-aware model is more granular, as it enforces conditioning) in the 5QI-aware model is more granular, as it not only enforce
not only per slice capacity constraints, but may as well enforce the s
per-slice capacity constraints, but may also enforce the
constraints per 5G QoS Class within each slice.</t> constraints per 5G QoS Class within each slice.</t>
<t>A 5G slice using multiple 5QIs can potentially specify rates in o ne of <t>A 5G slice using multiple 5QIs can potentially specify rates in o ne of
the following ways:</t> the following ways:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Rates per traffic class (CIR or CIR+PIR), no rate per slice ( sum <t>Rates per traffic class (CIR or CIR+PIR), no rate per slice ( sum
of rates per class gives the rate per slice).</t> of rates per class gives the rate per slice).</t>
</li> </li>
<li> <li>
<t>Rate per slice (CIR or CIR+PIR), and rates per prioritized <t>Rate per slice (CIR or CIR+PIR), and rates per prioritized
(premium) traffic classes (CIR only). Best effort traffic class (premium) traffic classes (CIR only). A best-effort traffic class
uses the bandwidth (within slice CIR/PIR) not consumed by uses the bandwidth (within slice CIR/PIR) not consumed by
prioritized classes.</t> prioritized classes.</t>
</li> </li>
</ul> </ul>
<t>In the first option, the slice admission control is executed with <t>In the first option, the slice admission control is executed with
traffic class granularity, as outlined in <xref target="_figure-20"/>. In th is model, traffic class granularity, as outlined in <xref target="_figure-20"/>. In th is model,
if a premium class doesn't consume all available class capacity, it if a premium class doesn't consume all available class capacity, it
cannot be reused by non-premium (i.e., Best Effort) class.</t> cannot be reused by a non-premium (i.e., best effort) class.</t>
<figure anchor="_figure-20"> <figure anchor="_figure-20">
<name>Ingress Slice Admission Control (5QI-aware Model)</name> <name>Ingress Slice Admission Control (5QI-Aware Model)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="560" width="408" viewBox="0 0 408 560" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="560" width="408" viewBox="0 0 408 560" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 296,48 L 296,192" fill="none" stroke="black"/> <path d="M 296,48 L 296,192" fill="none" stroke="black"/>
<path d="M 296,224 L 296,352" fill="none" stroke="black"/> <path d="M 296,224 L 296,352" fill="none" stroke="black"/>
<path d="M 296,384 L 296,528" fill="none" stroke="black"/> <path d="M 296,384 L 296,528" fill="none" stroke="black"/>
<path d="M 320,32 L 320,48" fill="none" stroke="black"/> <path d="M 320,32 L 320,48" fill="none" stroke="black"/>
<path d="M 320,528 L 320,544" fill="none" stroke="black"/> <path d="M 320,528 L 320,544" fill="none" stroke="black"/>
<path d="M 352,48 L 352,192" fill="none" stroke="black"/> <path d="M 352,48 L 352,192" fill="none" stroke="black"/>
<path d="M 352,224 L 352,352" fill="none" stroke="black"/> <path d="M 352,224 L 352,352" fill="none" stroke="black"/>
<path d="M 352,384 L 352,528" fill="none" stroke="black"/> <path d="M 352,384 L 352,528" fill="none" stroke="black"/>
skipping to change at line 4646 skipping to change at line 5319
| c | | | c | |
| e | | | e | |
BE CIR/PIR-3D-------<>-----------|--> | | BE CIR/PIR-3D-------<>-----------|--> | |
| 3 | | | 3 | |
| | | | | |
+--|---+ | +--|---+ |
+---------+ +---------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The second model combines the advantages of 5QI-unaware model (pe <t>The second option combines the advantages of the 5QI-unaware mode
r l (per-slice
slice admission control) with the per traffic class admission admission control) with per-traffic-class admission
control, as outlined in <xref target="_figure-20"/>. Ingress admission contr ol is at control, as outlined in <xref target="_figure-20"/>. Ingress admission contr ol is at
class granularity for premium classes (CIR only). Non-premium class class granularity for premium classes (CIR only). A non-premium class
(i.e., Best Effort) has no separate class admission control policy, (i.e., best-effort class) has no separate class admission control policy,
but it is allowed to use the entire slice capacity, which is available at but it is allowed to use the entire slice capacity, which is available at
any given moment. I.e., slice capacity, which is not consumed by any given moment (i.e., slice capacity, which is not consumed by
premium classes. It is a hierarchical model, as depicted in premium classes). It is a hierarchical model, as depicted in
<xref target="_figure-21"/>.</t> <xref target="_figure-21"/>.</t>
<figure anchor="_figure-21"> <figure anchor="_figure-21">
<name>Ingress Slice Admission Control (5QI-aware) - Hierarchical</ name> <name>Ingress Slice Admission Control (5QI-Aware Model) - Hierarch ical</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="576" width="408" viewBox="0 0 408 576" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="576" width="408" viewBox="0 0 408 576" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 256,80 L 256,208" fill="none" stroke="black"/> <path d="M 256,80 L 256,208" fill="none" stroke="black"/>
<path d="M 256,240 L 256,368" fill="none" stroke="black"/> <path d="M 256,240 L 256,368" fill="none" stroke="black"/>
<path d="M 256,400 L 256,528" fill="none" stroke="black"/> <path d="M 256,400 L 256,528" fill="none" stroke="black"/>
<path d="M 272,80 L 272,208" fill="none" stroke="black"/> <path d="M 272,80 L 272,208" fill="none" stroke="black"/>
<path d="M 272,240 L 272,368" fill="none" stroke="black"/> <path d="M 272,240 L 272,368" fill="none" stroke="black"/>
<path d="M 272,400 L 272,528" fill="none" stroke="black"/> <path d="M 272,400 L 272,528" fill="none" stroke="black"/>
<path d="M 296,64 L 296,208" fill="none" stroke="black"/> <path d="M 296,64 L 296,208" fill="none" stroke="black"/>
<path d="M 296,240 L 296,368" fill="none" stroke="black"/> <path d="M 296,240 L 296,368" fill="none" stroke="black"/>
skipping to change at line 4879 skipping to change at line 5552
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="outbound-edge-resource-control-1"> <section anchor="outbound-edge-resource-control-1">
<name>Outbound Edge Resource Control</name> <name>Outbound Edge Resource Control</name>
<t><xref target="_figure-22"/> outlines the outbound edge resource c ontrol model at the <t><xref target="_figure-22"/> outlines the outbound edge resource c ontrol model at the
transport network layer for 5QI-aware slices. Each slice is assigned transport network layer for 5QI-aware slices. Each slice is assigned
multiple egress queues. The sum of queue weights, which are 5Q QoS multiple egress queues. The sum of queue weights, which are 5Q QoS
queue CIRs within the slice, should not exceed the CIR of the slice queue CIRs within the slice, should not exceed the CIR of the slice
itself. And, similarly to the 5QI-aware model, the sum of slice CIRs itself. And, similar to the 5QI-aware model, the sum of slice CIRs
should not exceed the physical capacity of the AC.</t> should not exceed the physical capacity of the AC.</t>
<figure anchor="_figure-22"> <figure anchor="_figure-22">
<name>Egress Slice Admission Control (5QI-aware)</name> <name>Egress Slice Admission Control (5QI-Aware Model)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="656" width="552" viewBox="0 0 552 656" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="656" width="552" viewBox="0 0 552 656" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 32,32 L 32,640" fill="none" stroke="black"/> <path d="M 32,32 L 32,640" fill="none" stroke="black"/>
<path d="M 80,48 L 80,624" fill="none" stroke="black"/> <path d="M 80,48 L 80,624" fill="none" stroke="black"/>
<path d="M 112,32 L 112,48" fill="none" stroke="black"/> <path d="M 112,32 L 112,48" fill="none" stroke="black"/>
<path d="M 112,624 L 112,640" fill="none" stroke="black"/> <path d="M 112,624 L 112,640" fill="none" stroke="black"/>
<path d="M 144,48 L 144,64" fill="none" stroke="black"/> <path d="M 144,48 L 144,64" fill="none" stroke="black"/>
<path d="M 144,240 L 144,272" fill="none" stroke="black"/> <path d="M 144,240 L 144,272" fill="none" stroke="black"/>
<path d="M 144,312 L 144,376" fill="none" stroke="black"/> <path d="M 144,312 L 144,376" fill="none" stroke="black"/>
<path d="M 144,432 L 144,456" fill="none" stroke="black"/> <path d="M 144,432 L 144,456" fill="none" stroke="black"/>
skipping to change at line 5194 skipping to change at line 5867
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - - | +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
+---------+ +---------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="transit-resource-control"> <section anchor="transit-resource-control">
<name>Transit Resource Control</name> <name>Transit Resource Control</name>
<t>Transit resource control is much simpler than Edge resource control i n the provider network. <t>Transit resource control is much simpler than edge resource control i n the provider network.
As outlined in <xref target="_figure-QoS-5QI-aware"/>, at the provider networ k edge, 5Q QoS Class marking As outlined in <xref target="_figure-QoS-5QI-aware"/>, at the provider networ k edge, 5Q QoS Class marking
(represented by DSCP related to 5QI set by mobile network functions (represented by DSCP related to 5QI set by mobile network functions
in the packets handed off to the TN) is mapped to the TN QoS Class. in the packets handed off to the TN) is mapped to the TN QoS Class.
Based on TN QoS Class, when the packet is encapsulated with outer Based on TN QoS Class, when the packet is encapsulated with an outer
header (MPLS or IPv6), TN QoS Class marking (MPLS TC or IPv6 DSCP in header (MPLS or IPv6), the TN QoS Class marking (MPLS TC or IPv6 DSCP in
outer header, as depicted in Figures <xref format="counter" target="_figure-1 5"/> and <xref format="counter" target="_figure-16"/>) is set in the outer header, as depicted in Figures <xref format="counter" target="_figure-1 5"/> and <xref format="counter" target="_figure-16"/>) is set in the
outer header. PHB in provider network transit routers is based exclusively o n that TN QoS outer header. PHB in provider network transit routers is based exclusively o n that TN QoS
Class marking, i.e., original 5G QoS Class DSCP is not taken into Class marking, i.e., original 5G QoS Class DSCP is not taken into
consideration on transit.</t> consideration on transit.</t>
<t>Provider network transit resource control does not use any inbound in <t>Provider network transit resource control does not use any inbound in
terface policy, terface policy
but only outbound interface policy, which is based on priority queue but only uses an outbound interface policy, which is based on the priority qu
combined with weighted or deficit queuing model, without any shaper. eue
combined with a weighted or deficit queuing model, without any shaper.
The main purpose of transit resource control is to ensure that during The main purpose of transit resource control is to ensure that during
network congestion events, for example caused by network failures and network congestion events (for example, events caused by network failures or
temporary rerouting, premium classes are prioritized, and any drops temporary rerouting), premium classes are prioritized, and any drops
only occur in traffic that was de-prioritized by ingress admission control <x only occur in traffic that was deprioritized by ingress admission control (se
ref target="sec-inbound-edge-resource-control"/> or in non-premium (best-effort) e <xref target="sec-inbound-edge-resource-control"/>) or in non-premium (best-ef
classes. Capacity planning and management, as described in <xref target="sec-c fort) classes. Capacity planning and management, as described in <xref target="
apacity-planning"/>, ensures that enough sec-capacity-planning"/>, ensures that enough
capacity is available to fulfill all approved slice requests.</t> capacity is available to fulfill all approved slice requests.</t>
</section> </section>
</section> </section>
<section anchor="transport-plane-mapping-models"> <section anchor="transport-plane-mapping-models">
<name>PE Underlay Transport Mapping Models</name> <name>PE Underlay Transport Mapping Models</name>
<t>The PE underlay transport (underlay transport, for short) refers to a s pecific path forwarding behavior between PEs in order to provide packet delivery that is consistent with the corresponding SLOs. This realization step focuses o n controlling the paths that will be used for packet delivery between PEs, indep endent of the underlying network resource partitioning.</t> <t>The PE underlay transport (underlay transport, for short) refers to a s pecific path forwarding behavior between PEs in order to provide packet delivery that is consistent with the corresponding SLOs. This realization step focuses o n controlling the paths that will be used for packet delivery between PEs, indep endent of the underlying network resource partitioning.</t>
<t>It is worth noting that TN QoS Classes and underlay transport are each <t>It is worth noting that TN QoS Classes and underlay transport are each
related to different engineering objectives. The TN domain can be operated with related to different engineering objectives. For example, the TN domain can be
, e.g., 8 TN QoS Classes (representing 8 hardware queues in the operated with 8 TN QoS Classes (representing 8 hardware queues in the
routers), and two underlay transports (e.g., latency optimized underlay routers) and two underlay transports (e.g., a latency-optimized underlay
transport using link latency metrics for path calculation, and underlay transport using link-latency metrics for path calculation and an underlay
transport following Interior Gateway Protocol (IGP) metrics). TN QoS Class d transport following IGP metrics). The TN QoS Class determines the per-hop
etermines the per-hop
behavior when the packets are transiting through the provider network, behavior when the packets are transiting through the provider network,
while underlay transport determines the paths for packets through provider while underlay transport determines the paths for packets through the provide r
network based on the operator's requirements. This path can be optimized or c onstrained.</t> network based on the operator's requirements. This path can be optimized or c onstrained.</t>
<t>A network operator can define multiple underlay transports within a sin gle NRP. An underlay transport may be realized in multiple ways such as (but not limited to):</t> <t>A network operator can define multiple underlay transports within a sin gle NRP. An underlay transport may be realized in multiple ways such as (but not limited to):</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A mesh of RSVP-TE <xref target="RFC3209"/> or SR-TE <xref target="R FC9256"/> tunnels created with specific optimization criteria and <t>A mesh of RSVP-TE <xref target="RFC3209"/> or SR-TE <xref target="R FC9256"/> tunnels created with specific optimization criteria and
constraints. For example, mesh "A" might represent tunnels optimized for late ncy, and mesh "B" might represent tunnels optimized for high capacity.</t> constraints. For example, mesh "A" might represent tunnels optimized for late ncy, and mesh "B" might represent tunnels optimized for high capacity.</t>
</li> </li>
<li> <li>
<t>A Flex-Algorithm <xref target="RFC9350"/> with a particular metric- type (e.g., latency), or one that only uses links with particular properties (e. g., MACsec link <xref target="IEEE802.1AE"/>), or excludes links that are within a particular geography.</t> <t>A Flex-Algorithm <xref target="RFC9350"/> with a particular metric- type (e.g., latency), or one that only uses links with particular properties (e. g., a Media Access Control Security (MACsec) link <xref target="IEEE802.1AE"/>) or excludes links that are within a particular geography.</t>
</li> </li>
</ul> </ul>
<t>These protocols can be controlled, e.g., by tuning the protocol list un der the "underlay-transport" data node defined in the L3VPN Network Model (L3NM) <xref target="RFC9182"/> and the L2VPN Network Model (L2NM) <xref target="RFC92 91"/>.</t> <t>These protocols can be controlled, e.g., by tuning the protocol list un der the "underlay-transport" data node defined in the L3VPN Network Model (L3NM) <xref target="RFC9182"/> and the L2VPN Network Model (L2NM) <xref target="RFC92 91"/>.</t>
<!-- [rfced] May we update "2024" as follows in these sentences?
Original:
However, such an approach is left out of the scope given the current
state of the technology (2024).
...
it is not necessary (or indeed possible for
current SR-TE technology in 2024) to reserve bandwidth at the network
layer.
Perhaps:
However, such an approach is out of the scope given the current
state of the technology at the time of writing this document.
...
it is not necessary (or indeed possible for
current SR-TE technology at the time of writing this document) to reserve
bandwidth at the network layer.
-->
<t>Also, underlay transports may be realized using separate NRPs. However, such an approach is left out of the scope given the current state of the techno logy (2024).</t> <t>Also, underlay transports may be realized using separate NRPs. However, such an approach is left out of the scope given the current state of the techno logy (2024).</t>
<t>Similar to the QoS mapping models discussed in <xref target="sec-qos-ma p"/>, for mapping <t>Similar to the QoS mapping models discussed in <xref target="sec-qos-ma p"/>, for mapping
to underlay transports at the ingress PE, both 5QI-unaware and 5QI-aware to underlay transports at the ingress PE, both the 5QI-unaware and 5QI-aware
models are defined. Essentially, entire slices can be mapped to models are defined. Essentially, entire slices can be mapped to
underlay transports without 5G QoS consideration (5QI-unaware model). For exa mple, underlay transports without 5G QoS consideration (5QI-unaware model). For exa mple,
flows with different 5G QoS Classes, even from same flows with different 5G QoS Classes, even from same
slice, can be mapped to different underlay transports (5QI-aware slice, can be mapped to different underlay transports (5QI-aware
model).</t> model).</t>
<t><xref target="_figure-23"/> depicts an example of a simple network with two underlay transports, <t><xref target="_figure-23"/> depicts an example of a simple network with two underlay transports,
each using a mesh of TE tunnels with or without Path Computation Element (PCE ) <xref target="RFC5440"/>, and with or without per-path bandwidth each using a mesh of TE tunnels with or without Path Computation Element (PCE ) <xref target="RFC5440"/> and with or without per-path bandwidth
reservations. reservations.
<xref target="sec-capacity-planning"/> discusses in detail different bandwidt h <xref target="sec-capacity-planning"/> discusses in detail different bandwidt h
models that can be deployed in the provider network. However, models that can be deployed in the provider network. However,
discussion about how to realize or orchestrate underlay transports is discussion about how to realize or orchestrate underlay transports is
out of scope for this document.</t> out of scope for this document.</t>
<figure anchor="_figure-23"> <figure anchor="_figure-23">
<name>Example of Underlay Transport Relying on TE Tunnels</name> <name>Example of Underlay Transport Relying on TE Tunnels</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="400" width="496" viewBox="0 0 496 400" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="400" width="496" viewBox="0 0 496 400" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,32 L 8,368" fill="none" stroke="black"/> <path d="M 8,32 L 8,368" fill="none" stroke="black"/>
skipping to change at line 5402 skipping to change at line 6095
| | B o-----+ +---------------+ | | | | B o-----+ +---------------+ | |
| | | | | | | | | | | | | | | |
| +----------+ | | +---+ +---+ | +------+ +------+ | +----------+ | | +---+ +---+ | +------+ +------+
| | | | | | | +-------------->| PE-D | | | | | | | | +-------------->| PE-D |
+---------------+ +---+ +---+ +--------------->>| | +---------------+ +---+ +---+ +--------------->>| |
+------+ +------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>For illustration purposes, <xref target="_figure-23"/> shows only singl e <t>For illustration purposes, <xref target="_figure-23"/> shows only singl e
tunnels per underlay transport for (ingress PE, egress PE) pair. However, the re might be multiple tunnels within a single underlay transport tunnels per underlay transport for an (ingress PE, egress PE) pair. However, there might be multiple tunnels within a single underlay transport
between any pair of PEs.</t> between any pair of PEs.</t>
<section anchor="qi-unaware-model"> <section anchor="qi-unaware-model">
<name>5QI-unaware Model</name> <name>5QI-Unaware Model</name>
<t>As discussed in <xref target="sec-5QI-unaware"/>, in the 5QI-unaware model, the provider network <t>As discussed in <xref target="sec-5QI-unaware"/>, in the 5QI-unaware model, the provider network
doesn't take into account 5G QoS during execution of per-hop doesn't take into account 5G QoS during execution of per-hop
behavior. The entire slice is mapped to single TN QoS Class, behavior. The entire slice is mapped to a single TN QoS Class;
therefore the entire slice is subject to the same per-hop behavior. therefore, the entire slice is subject to the same per-hop behavior.
Similarly, in 5QI-unaware PE underlay transport mapping model, the entire Similarly, in the 5QI-unaware PE underlay transport mapping model, the entire
slice is mapped to a single underlay transport, as depicted in slice is mapped to a single underlay transport, as depicted in
<xref target="_figure-24"/>.</t> <xref target="_figure-24"/>.</t>
<figure anchor="_figure-24"> <figure anchor="_figure-24">
<name>Network Slice to PEs Underlay Transport Mapping (5QI-unaware Mod el)</name> <name>Mapping of Network Slice to Underlay Transport (5QI-Unaware Mode l)</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="608" width="368" viewBox="0 0 368 608" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="608" width="368" viewBox="0 0 368 608" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,32 L 8,48" fill="none" stroke="black"/> <path d="M 8,32 L 8,48" fill="none" stroke="black"/>
<path d="M 24,96 L 24,160" fill="none" stroke="black"/> <path d="M 24,96 L 24,160" fill="none" stroke="black"/>
<path d="M 24,192 L 24,256" fill="none" stroke="black"/> <path d="M 24,192 L 24,256" fill="none" stroke="black"/>
<path d="M 24,288 L 24,352" fill="none" stroke="black"/> <path d="M 24,288 L 24,352" fill="none" stroke="black"/>
<path d="M 24,384 L 24,448" fill="none" stroke="black"/> <path d="M 24,384 L 24,448" fill="none" stroke="black"/>
<path d="M 24,480 L 24,544" fill="none" stroke="black"/> <path d="M 24,480 L 24,544" fill="none" stroke="black"/>
<path d="M 48,112 L 48,144" fill="none" stroke="black"/> <path d="M 48,112 L 48,144" fill="none" stroke="black"/>
<path d="M 48,208 L 48,240" fill="none" stroke="black"/> <path d="M 48,208 L 48,240" fill="none" stroke="black"/>
skipping to change at line 5633 skipping to change at line 6326
: | | NS 5 +-----------+ | : | | NS 5 +-----------+ |
: | +----------+ | : | : | +----------+ | : |
: '--------------' : | : '--------------' : |
'.. .. .. .. .. .. .' | '.. .. .. .. .. .. .' |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="qi-aware-model-1"> <section anchor="qi-aware-model-1">
<name>5QI-aware Model</name> <name>5QI-Aware Model</name>
<t>In 5QI-aware model, the traffic can be mapped to underlay transports <t>In the 5QI-aware model, the traffic can be mapped to underlay transpo
at rts at
the granularity of 5G QoS Class. Given that the potential number of the granularity of 5G QoS Class. Given that the potential number of
underlay transports is limited, packets from multiple 5G QoS Classes underlay transports is limited, packets from multiple 5G QoS Classes
with similar characteristics are mapped to a common underlay transport, with similar characteristics are mapped to a common underlay transport,
as depicted in <xref target="_figure-25"/>.</t> as depicted in <xref target="_figure-25"/>.</t>
<figure anchor="_figure-25"> <figure anchor="_figure-25">
<name>Network Slice to Underlay Transport Mapping (5QI-aware Model)</n ame> <name>Mapping of Network Slice to Underlay Transport (5QI-Aware Model) </name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="608" width="400" viewBox="0 0 400 608" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="608" width="400" viewBox="0 0 400 608" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 24,32 L 24,48" fill="none" stroke="black"/> <path d="M 24,32 L 24,48" fill="none" stroke="black"/>
<path d="M 40,96 L 40,304" fill="none" stroke="black"/> <path d="M 40,96 L 40,304" fill="none" stroke="black"/>
<path d="M 40,336 L 40,544" fill="none" stroke="black"/> <path d="M 40,336 L 40,544" fill="none" stroke="black"/>
<path d="M 168,80 L 168,120" fill="none" stroke="black"/> <path d="M 168,80 L 168,120" fill="none" stroke="black"/>
<path d="M 168,136 L 168,168" fill="none" stroke="black"/> <path d="M 168,136 L 168,168" fill="none" stroke="black"/>
<path d="M 168,184 L 168,216" fill="none" stroke="black"/> <path d="M 168,184 L 168,216" fill="none" stroke="black"/>
<path d="M 168,232 L 168,264" fill="none" stroke="black"/> <path d="M 168,232 L 168,264" fill="none" stroke="black"/>
<path d="M 168,320 L 168,344" fill="none" stroke="black"/> <path d="M 168,320 L 168,344" fill="none" stroke="black"/>
skipping to change at line 5920 skipping to change at line 6613
</section> </section>
<section anchor="sec-capacity-planning"> <section anchor="sec-capacity-planning">
<name>Capacity Planning/Management</name> <name>Capacity Planning/Management</name>
<section anchor="bandwidth-requirements"> <section anchor="bandwidth-requirements">
<name>Bandwidth Requirements</name> <name>Bandwidth Requirements</name>
<t>This section describes the information conveyed by the 5G NSO to the <t>This section describes the information conveyed by the 5G NSO to the
NSC with respect to slice bandwidth requirements.</t> NSC with respect to slice bandwidth requirements.</t>
<t><xref target="_figure-multi-DC"/> shows three DCs that contain instan ces of network <t><xref target="_figure-multi-DC"/> shows three DCs that contain instan ces of network
functions. Also shown are PEs that have links to the DCs. The PEs functions. Also shown are PEs that have links to the DCs. The PEs
belong to the provider network. Other details of the provider belong to the provider network. Other details of the provider
network, such as P-routers and transit links are not shown. Also network, such as P-routers and transit links, are not shown. In addition,
details of the DC infrastructure in customer sites, such as switches and rout ers, are not details of the DC infrastructure in customer sites, such as switches and rout ers, are not
shown.</t> shown.</t>
<t>The 5G NSO is aware of the existence of the network functions and the ir <t>The 5G NSO is aware of the existence of the network functions and the ir
locations. However, it is not aware of the details of the provider locations. However, it is not aware of the details of the provider
network. The NSC has the opposite view - it is network. The NSC has the opposite view -- it is
aware of the provider network infrastructure and the links between the PEs aware of the provider network infrastructure and the links between the PEs
and the DCs, but is not aware of the individual network functions at customer sites.</t> and the DCs, but it is not aware of the individual network functions at custo mer sites.</t>
<figure anchor="_figure-multi-DC"> <figure anchor="_figure-multi-DC">
<name>An Example of Multi-DC Architecture</name> <name>Example of Multi-DC Architecture</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="576" viewBox="0 0 576 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="576" viewBox="0 0 576 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,32 L 8,208" fill="none" stroke="black"/> <path d="M 8,32 L 8,208" fill="none" stroke="black"/>
<path d="M 24,64 L 24,96" fill="none" stroke="black"/> <path d="M 24,64 L 24,96" fill="none" stroke="black"/>
<path d="M 48,112 L 48,144" fill="none" stroke="black"/> <path d="M 48,112 L 48,144" fill="none" stroke="black"/>
<path d="M 64,160 L 64,192" fill="none" stroke="black"/> <path d="M 64,160 L 64,192" fill="none" stroke="black"/>
<path d="M 80,64 L 80,96" fill="none" stroke="black"/> <path d="M 80,64 L 80,96" fill="none" stroke="black"/>
<path d="M 104,112 L 104,144" fill="none" stroke="black"/> <path d="M 104,112 L 104,144" fill="none" stroke="black"/>
<path d="M 120,160 L 120,192" fill="none" stroke="black"/> <path d="M 120,160 L 120,192" fill="none" stroke="black"/>
<path d="M 176,32 L 176,208" fill="none" stroke="black"/> <path d="M 176,32 L 176,208" fill="none" stroke="black"/>
skipping to change at line 6107 skipping to change at line 6800
</figure> </figure>
<t>Let us consider 5G slice "X" that uses some of the network functions in <t>Let us consider 5G slice "X" that uses some of the network functions in
the three DCs. If this slice has latency requirements, the 5G NSO will the three DCs. If this slice has latency requirements, the 5G NSO will
have taken those into account when deciding which NF instances have taken those into account when deciding which NF instances
in which DC are to be invoked for this slice. As a result of such a in which DC are to be invoked for this slice. As a result of such a
placement decision, the three DCs shown are involved in 5G slice "X", placement decision, the three DCs shown are involved in 5G slice "X",
rather than other DCs. For its decision-making, the 5G NSO rather than other DCs. For its decision-making, the 5G NSO
needs information from the NSC about the observed latency between DCs. needs information from the NSC about the observed latency between DCs.
Preferably, the NSC would present the topology in an abstracted form, Preferably, the NSC would present the topology in an abstracted form,
consisting of point-to-point abstracted links between pairs of DCs consisting of point-to-point abstracted links between pairs of DCs
and associated latency and, optionally, delay variation and link loss and associated latency and, optionally, delay variation and link-loss
values. It would be valuable to have a mechanism for the 5G NSO to values. It would be valuable to have a mechanism for the 5G NSO to
inform the NSC which DC-pairs are of interest for these metrics - inform the NSC which DC-pairs are of interest for these metrics;
there may be of order thousands of DCs, but the 5G NSO will only be there may be thousands of DCs, but the 5G NSO will only be
interested in these metrics for a small fraction of all the possible interested in these metrics for a small fraction of all the possible
DC-pairs, i.e. those in the same region of the provider network. The DC-pairs, i.e., those in the same region of the provider network. The
mechanism for conveying the information is out of scope for this document.</t > mechanism for conveying the information is out of scope for this document.</t >
<t><xref target="_table-x"/> shows the matrix of bandwidth demands for 5 G slice "X". <t><xref target="_table-x"/> shows the matrix of bandwidth demands for 5 G slice "X".
Within the slice, multiple NF instances might be Within the slice, multiple NF instances might be
sending traffic from DCi to DCj. However, the 5G NSO sums the sending traffic from DCi to DCj. However, the 5G NSO sums the
associated demands into one value. For example, "NF1A" and "NF1B" in "DC1" associated demands into one value. For example, "NF1A" and "NF1B" in "DC1"
might be sending traffic to multiple NFs in "DC2", but this is might be sending traffic to multiple NFs in "DC2", but this is
expressed as one value in the traffic matrix: the total bandwidth expressed as one value in the traffic matrix: the total bandwidth
required for 5G slice "X" from "DC1" to "DC2" (8 units). Each row in the required for 5G slice "X" from "DC1" to "DC2" (8 units). Each row in the
right-most column in the traffic matrix shows the total amount of right-most column in the traffic matrix shows the total amount of
traffic going from a given DC into the transport network, regardless traffic going from a given DC into the transport network, regardless
of the destination DC. Note that this number can be less than the of the destination DC. Note that this number can be less than the
sum of DC-to-DC demands in the same row, on the basis that not all sum of DC-to-DC demands in the same row, on the basis that not all
the NFs are likely to be sending at their maximum rate the NFs are likely to be sending at their maximum rate
simultaneously. For example, the total traffic from "DC1" for slice "X" simultaneously. For example, the total traffic from "DC1" for slice "X"
is 11 units, which is less than the sum of the DC-to-DC demands in is 11 units, which is less than the sum of the DC-to-DC demands in
the same row (13 units). Note, as described in <xref target="sec-qos-map"/>, a slice the same row (13 units). Note, as described in <xref target="sec-qos-map"/>, a slice
may have per-QoS class bandwidth requirements, and may have CIR and may have per-QoS class bandwidth requirements and may have CIR and
PIR limits. This is not included in the example, but the same PIR limits. This is not included in the example, but the same
principles apply in such cases.</t> principles apply in such cases.</t>
<table anchor="_table-x">
<table anchor="_table-x">
<name>Inter-DC Traffic Demand Matrix (Slice X)</name> <name>Inter-DC Traffic Demand Matrix (Slice X)</name>
<thead> <thead>
<tr> <tr>
<th align="left">From/To</th> <th align="left">From/To</th>
<th align="left">DC 1</th> <th align="left">DC 1</th>
<th align="left">DC 2</th> <th align="left">DC 2</th>
<th align="left">DC 3</th> <th align="left">DC 3</th>
<th align="center">Total from DC</th> <th align="center">Total from DC</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 6167 skipping to change at line 6861
</tr> </tr>
<tr> <tr>
<td align="left">DC 3</td> <td align="left">DC 3</td>
<td align="left">4</td> <td align="left">4</td>
<td align="left">7</td> <td align="left">7</td>
<td align="left">n/a</td> <td align="left">n/a</td>
<td align="center">10.0</td> <td align="center">10.0</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> can be use
d to convey all <!-- [rfced] We updated "[I-D.ietf-teas-ietf-network-slice-nbi-yang]" in these
sentences to "the YANG data model defined in [NSSM]" for clarity. Let us
know any concerns.
Original:
[I-D.ietf-teas-ietf-network-slice-nbi-yang] can be used to convey all
of the information in the traffic matrix to an NSC.
...
...could be used instead of
[I-D.ietf-teas-ietf-network-slice-nbi-yang], as they support
conveying the bandwidth information in the right-most column of the
traffic matrix.
...
The 5G NSO can
use [I-D.ietf-teas-ietf-network-slice-nbi-yang] to request low-
latency transport for a given slice if required.
...
For example,
[I-D.ietf-teas-ietf-network-slice-nbi-yang] exposes a set of
statistics per SDP, connectivity construct, and connection group.
Updated:
The YANG data model defined in [NSSM] can be used to convey all of
the information in the traffic matrix to an NSC.
...
...could be used instead of the YANG
data model defined in [NSSM], as they support conveying the bandwidth
information in the right-most column of the traffic matrix.
...
The 5G NSO can
use the YANG data model defined in [NSSM] to request low-latency
transport for a given slice if required.
...
For example, the YANG data model defined
in [NSSM] exposes a set of statistics per SDP, connectivity
construct, and connection group.
-->
<t>The YANG data model defined in <xref target="I-D.ietf-teas-ietf-netwo
rk-slice-nbi-yang"/> can be used to convey all
of the information in the traffic matrix to an NSC. The of the information in the traffic matrix to an NSC. The
NSC applies policers corresponding to the last column in the traffic NSC applies policers corresponding to the last column in the traffic
matrix to the appropriate PE routers, in order to enforce the matrix to the appropriate PE routers, in order to enforce the
bandwidth contract. For example, it applies a policer of 11 units to bandwidth contract. For example, it applies a policer of 11 units to
PE1A and PE1B that face DC1, as this is the total bandwidth that DC1 PE1A and PE1B that face DC1, as this is the total bandwidth that DC1
sends into the provider network corresponding to Slice X. Also, the sends into the provider network corresponding to slice "X". Also, the
controller may apply shapers in the direction from the TN to the DC, controller may apply shapers in the direction from the TN to the DC
if otherwise there is the possibility of a link in the DC being if there is the possibility of a link in the DC being
oversubscribed. Note that a peer NF endpoint of an AC can be oversubscribed. Note that a peer NF endpoint of an AC can be
identified using 'peer-sap-id' as defined in <xref target="RFC9408"/>.</t> identified using "peer-sap-id" as defined in <xref target="RFC9408"/>.</t>
<t>Depending on the bandwidth model used in the provider network (<xref target="sec-bw"/>), <t>Depending on the bandwidth model used in the provider network (<xref target="sec-bw"/>),
the other values in the matrix, i.e., the DC-to-DC demands, may not the other values in the matrix, i.e., the DC-to-DC demands, may not
be directly applied to the provider network. Even so, the be directly applied to the provider network. Even so, the
information may be useful to the NSC for capacity planning and information may be useful to the NSC for capacity planning and
failure simulation purposes. If, on the other hand, the DC-to-DC failure simulation purposes. On the other hand, if the DC-to-DC
demand information is not used by the NSC, the IETF YANG Data demand information is not used by the NSC, the IETF YANG data
Model for L3VPN Service Delivery <xref target="RFC8299"/> or the IETF YANG Da models for L3VPN service delivery <xref target="RFC8299"/> or
ta L2VPN service delivery <xref target="RFC8466"/> could be used instead of the
Model for L2VPN Service Delivery <xref target="RFC8466"/> could be used inste YANG data model defined in
ad of
<xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>, as they support <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>, as they support
conveying the bandwidth information in the right-most column of the conveying the bandwidth information in the right-most column of the
traffic matrix.</t> traffic matrix.</t>
<t>The provider network may be implemented in such a way that it has <t>The provider network may be implemented in such a way that it has
various types of paths, for example low-latency traffic might be various types of paths, for example, low-latency traffic might be
mapped onto a different transport path to other traffic (for example mapped onto a different transport path from other traffic (for example,
a particular Flex-Algorithm, a particular set of TE paths, or a specific queu e <xref target="RFC9330"/>), as discussed a particular Flex-Algorithm, a particular set of TE paths, or a specific queu e <xref target="RFC9330"/>), as discussed
in <xref target="sec-qos-map"/>. The 5G NSO can use in <xref target="sec-qos-map"/>. The 5G NSO can use the YANG data model defi ned in
<xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> to request low-lat ency <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> to request low-lat ency
transport for a given slice if required. However, <xref target="RFC8299"/> o r transport for a given slice if required. However, the YANG data models in <x ref target="RFC8299"/> or
<xref target="RFC8466"/> do not support requesting a particular transport-typ e, <xref target="RFC8466"/> do not support requesting a particular transport-typ e,
e.g., low-latency. One option is to augment these models to convey e.g., low-latency. One option is to augment these models to convey
this information. This can be achieved by reusing the 'underlay- this information. This can be achieved by reusing the "underlay-transport" c
transport' construct defined in <xref target="RFC9182"/> and <xref target="RF onstruct defined in <xref target="RFC9182"/> and <xref target="RFC9291"/>.</t>
C9291"/>.</t>
</section> </section>
<section anchor="sec-bw"> <section anchor="sec-bw">
<name>Bandwidth Models</name> <name>Bandwidth Models</name>
<t>This section describes three bandwidth management schemes that could <t>This section describes three bandwidth management schemes that could
be employed in the provider network. Many variations are possible, be employed in the provider network. Many variations are possible,
but each example describes the salient points of the corresponding but each example describes the salient points of the corresponding
scheme. Schemes 2 and 3 use TE; other variations on TE are possible scheme. Schemes 2 and 3 use TE; other variations on TE are possible
as described in <xref target="RFC9522"/>.</t> as described in <xref target="RFC9522"/>.</t>
<section anchor="scheme-1-shortest-path-forwarding-spf"> <section anchor="scheme-1-shortest-path-forwarding-spf">
<name>Scheme 1: Shortest Path Forwarding (SPF)</name> <name>Scheme 1: Shortest Path Forwarding (SPF)</name>
<t>Shortest path forwarding is used according to the IGP metric. Give n <t>Shortest path forwarding is used according to the IGP metric. Give n
that some slices are likely to have latency SLOs, the IGP metric on that some slices are likely to have latency SLOs, the IGP metric on
each link can be set to be in proportion to the latency of the link. each link can be set to be in proportion to the latency of the link.
In this way, all traffic follows the minimum latency path between In this way, all traffic follows the minimum latency path between
endpoints.</t> endpoints.</t>
<t>In Scheme 1, although the operator provides bandwidth guarantees to <t>In Scheme 1, although the operator provides bandwidth guarantees to
the slice customers, there is no explicit end-to-end underpinning of the slice customers, there is no explicit end-to-end underpinning of
the bandwidth SLO, in the form of bandwidth reservations across the the bandwidth SLO, in the form of bandwidth reservations across the
provider network. Rather, the expected performance is achieved via provider network. Rather, the expected performance is achieved via
capacity planning, based on traffic growth trends and anticipated capacity planning, based on traffic growth trends and anticipated
future demands, in order to ensure that network links are not over- future demands, in order to ensure that network links are not over-subscribed
subscribed. This scheme is analogous to that used in many existing . This scheme is analogous to that used in many existing
business VPN deployments, in that bandwidth guarantees are provided business VPN deployments, in that bandwidth guarantees are provided
to the customers but are not explicitly underpinned end to end across to the customers but are not explicitly underpinned end to end across
the provider network.</t> the provider network.</t>
<t>A variation on the scheme is that Flex-Algorithm <xref target="RFC9 350"/> is used. For example, one Flex-Algorithm could <t>A variation on the scheme is that Flex-Algorithm <xref target="RFC9 350"/> is used. For example, one Flex-Algorithm could
use latency-based metrics and another Flex-Algorithm could use the IGP use latency-based metrics, and another Flex-Algorithm could use the IGP
metric. There would be a many-to-one mapping of Network Slices to Flex-Algori thms.</t> metric. There would be a many-to-one mapping of Network Slices to Flex-Algori thms.</t>
<t>While Scheme 1 is technically feasible, it is vulnerable to <t>While Scheme 1 is technically feasible, it is vulnerable to
unexpected changes in traffic patterns and/or network element unexpected changes in traffic patterns and/or network element
failures resulting in congestion. This is because, unlike Schemes 2 failures resulting in congestion. This is because, unlike Schemes 2
and 3 which employ TE, traffic cannot be diverted from the shortest and 3, which employ TE, traffic cannot be diverted from the shortest
path.</t> path.</t>
</section> </section>
<section anchor="scheme-2-te-paths-with-fixed-bandwidth-reservations"> <section anchor="scheme-2-te-paths-with-fixed-bandwidth-reservations">
<name>Scheme 2: TE Paths with Fixed Bandwidth Reservations</name> <name>Scheme 2: TE Paths with Fixed Bandwidth Reservations</name>
<t>Scheme 2 uses RSVP-TE <xref target="RFC3209"/> or SR-TE paths <xref target="RFC9256"/> with fixed bandwidth <t>Scheme 2 uses RSVP-TE <xref target="RFC3209"/> or SR-TE <xref targe t="RFC9256"/> paths with fixed bandwidth
reservations. By "fixed", we mean a value that stays constant over reservations. By "fixed", we mean a value that stays constant over
time, unless the 5G NSO communicates a change in slice bandwidth time, unless the 5G NSO communicates a change in slice bandwidth
requirements, due to the creation or modification of a slice. Note requirements, due to the creation or modification of a slice. Note
that the "reservations" may be maintained by the transport that the "reservations" may be maintained by the transport
controller - it is not necessary (or indeed possible for current SR-TE techno logy in 2024) to controller; it is not necessary (or indeed possible for current SR-TE technol ogy in 2024) to
reserve bandwidth at the network layer. The bandwidth requirement reserve bandwidth at the network layer. The bandwidth requirement
acts as a constraint whenever the controller (re)computes a path. There coul d be a single mesh of paths between endpoints that acts as a constraint whenever the controller (re)computes a path. There coul d be a single mesh of paths between endpoints that
carry all of the traffic types, or there could be a small handful of carry all of the traffic types, or there could be a small handful of
meshes, for example one mesh for low-latency traffic that follows the meshes, for example, one mesh for low-latency traffic that follows the
minimum latency path and another mesh for the other traffic that minimum latency path and another mesh for the other traffic that
follows the minimum IGP metric path, as described in <xref target="sec-qos-ma p"/>. follows the minimum IGP metric path, as described in <xref target="sec-qos-ma p"/>.
There would be a many-to-one mapping of slices to paths.</t> There would be a many-to-one mapping of slices to paths.</t>
<t>The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj <t>The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj
demands of the individual slices. For example, if only slices "X" and demands of the individual slices. For example, if only slices "X" and
"Y" are present, then the bandwidth requirement from "DC1" to "DC2" "Y" are present, then the bandwidth requirement from "DC1" to "DC2"
is 12 units (8 units for slice "X" (<xref target="_table-x"/>) and 4 units fo r slice "Y" (<xref target="_table-y"/>)). When the is 12 units (8 units for slice "X" (<xref target="_table-x"/>) and 4 units fo r slice "Y" (<xref target="_table-y"/>)). When the
5G NSO requests a new slice, the NSC, 5G NSO requests a new slice, the NSC,
increments the bandwidth requirement according to the requirements of increments the bandwidth requirement according to the requirements of
the new slice. For example, in <xref target="_figure-multi-DC"/>, suppose a new slice is the new slice. For example, in <xref target="_figure-multi-DC"/>, suppose a new slice is
skipping to change at line 6301 skipping to change at line 7032
<td align="center">5.1</td> <td align="center">5.1</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>In the example, each DC has two PEs facing it for reasons of <t>In the example, each DC has two PEs facing it for reasons of
resilience. The NSC needs to determine how to map resilience. The NSC needs to determine how to map
the "DC1" to "DC2" bandwidth requirement to bandwidth reservations of TE the "DC1" to "DC2" bandwidth requirement to bandwidth reservations of TE
LSPs from "DC1" to "DC2". For example, if the routing configuration is LSPs from "DC1" to "DC2". For example, if the routing configuration is
arranged such that in the absence of any network failure, traffic arranged such that in the absence of any network failure, traffic
from "DC1" to "DC2" always enters "PE1A" and goes to "PE2A", the controller from "DC1" to "DC2" always enters "PE1A" and goes to "PE2A", the controller
reserves 12.8 Gbps of bandwidth on the path from "PE1A" to "PE2A". If, on reserves 12.8 Gbps of bandwidth on the path from "PE1A" to "PE2A". On
the other hand, the routing configuration is arranged such that in the other hand, if the routing configuration is arranged such that in
the absence of any network failure, traffic from "DC1" to "DC2" always the absence of any network failure, traffic from "DC1" to "DC2" always
enters "PE1A" and is load-balanced across "PE2A" and "PE2B", the controller enters "PE1A" and is load-balanced across "PE2A" and "PE2B", the controller
reserves 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2A" and reserves 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2A" and
6.4 Gbps of bandwidth on the path from "PE1A" to "PE2B". It might be tricky 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2B". It might be tricky
for the NSC to be aware of all conditions that for the NSC to be aware of all conditions that
change the way traffic lands on the various PEs, and therefore know change the way traffic lands on the various PEs and therefore know
that it needs to change bandwidth reservations of paths accordingly. that it needs to change bandwidth reservations of paths accordingly.
For example, there might be an internal failure within "DC1" that For example, there might be an internal failure within "DC1" that
causes traffic from "DC1" to land on "PE1B", rather than "PE1A". The causes traffic from "DC1" to land on "PE1B" rather than "PE1A". The
NSC may not be aware of the failure and therefore NSC may not be aware of the failure and therefore
may not know that it now needs to apply bandwidth reservations to may not know that it now needs to apply bandwidth reservations to
paths from "PE1B" to "PE2A" / "PE2B".</t> paths from "PE1B" to "PE2A" and "PE2B".</t>
</section> </section>
<section anchor="scheme-3-te-paths-without-bandwidth-reservation"> <section anchor="scheme-3-te-paths-without-bandwidth-reservation">
<name>Scheme 3: TE Paths without Bandwidth Reservation</name> <name>Scheme 3: TE Paths without Bandwidth Reservation</name>
<t>Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could b e a <t>Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could b e a
single mesh of paths between endpoints that carry all of the traffic single mesh of paths between endpoints that carry all of the traffic
types, or there could be a small handful of meshes, for example one types, or there could be a small handful of meshes, for example, one
mesh for low-latency traffic that follows the minimum latency path mesh for low-latency traffic that follows the minimum latency path
and another mesh for the other traffic that follows the minimum IGP and another mesh for the other traffic that follows the minimum IGP
metric path, as described in <xref target="sec-qos-map"/>. There would be a many-to-one metric path, as described in <xref target="sec-qos-map"/>. There would be a many-to-one
mapping of slices to paths.</t> mapping of slices to paths.</t>
<t>The difference between Scheme 2 and Scheme 3 is that Scheme 3 does
<!-- [rfced] Please confirm that "the paths of one or more paths" is correct
here.
Original:
In this
approach, when the actual traffic volume in the data plane on given
link exceeds a threshold, the controller, knowing how much actual
data plane traffic is currently traveling along each RSVP or SR-TE
path, can tune the paths of one or more paths using the link such
that they avoid that link. This approach is similar to that
described in Section 4.3.1 of [RFC9522].
Perhaps:
In this
approach, when the actual traffic volume in the data plane on given
link exceeds a threshold, the controller, knowing how much actual
data plane traffic is currently traveling along each RSVP or SR-TE
path, can tune one or more paths using the link such
that they avoid that link. This approach is similar to that
described in Section 4.3.1 of [RFC9522].
-->
<t>The difference between Scheme 2 and Scheme 3 is that Scheme 3 does
not have fixed bandwidth reservations for the paths. Instead, actual not have fixed bandwidth reservations for the paths. Instead, actual
measured data-plane traffic volumes are used to influence the measured data plane traffic volumes are used to influence the
placement of TE paths. One way of achieving this is to use placement of TE paths. One way of achieving this is to use
distributed RSVP-TE with auto-bandwidth. Alternatively, the distributed RSVP-TE with auto-bandwidth. Alternatively, the
NSC can use telemetry-driven automatic congestion NSC can use telemetry-driven automatic congestion
avoidance. In this approach, when the actual traffic volume in the avoidance. In this approach, when the actual traffic volume in the
data plane on given link exceeds a threshold, the controller, knowing data plane on a given link exceeds a threshold, the controller, knowing
how much actual data plane traffic is currently traveling along each how much actual data plane traffic is currently traveling along each
RSVP or SR-TE path, can tune the paths of one or more paths using the RSVP or SR-TE path, can tune the paths of one or more paths using the
link such that they avoid that link. This approach is similar to that describ ed in <xref section="4.3.1" sectionFormat="of" target="RFC9522"/>.</t> link such that they avoid that link. This approach is similar to that describ ed in <xref section="4.3.1" sectionFormat="of" target="RFC9522"/>.</t>
<t>It would be undesirable to move a path that has latency as its cost function, rather than <t>It would be undesirable to move a path that has latency as its cost function, rather than
another type of path, in order to ease the congestion, as the altered path another type of path, in order to ease the congestion, as the altered path
will typically have a higher latency. This can be avoided by will typically have a higher latency. This can be avoided by
designing the algorithms described in the previous paragraph such designing the algorithms described in the previous paragraph such
that they avoid moving minimum-latency paths unless there is no that they avoid moving minimum-latency paths unless there is no
alternative.</t> alternative.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="network-slicing-oam"> <section anchor="network-slicing-oam">
<name>Network Slicing OAM</name> <name>Network Slicing OAM</name>
<t>The deployment and maintenance of slices within a network imply <t>The deployment and maintenance of slices within a network imply
that a set of OAM functions (<xref target="RFC6291"/>) need to be deployed by the providers, e.g.:</t> that a set of OAM functions <xref target="RFC6291"/> need to be deployed by t he providers, for example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Providers should be able to execute OAM tasks on a per Network Slic e <t>Providers should be able to execute OAM tasks on a per Network Slic e
basis. These tasks can cover the "full" slice within a domain or a basis. These tasks can cover the "full" slice within a domain or a
portion of that slice (for troubleshooting purposes, for example). </t> portion of that slice (for troubleshooting purposes, for example). </t>
<t> <t>
For example, per-slice OAM tasks can consist of (but not limited to): </t> For example, per-slice OAM tasks can consist of (but not limited to): </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>tracing resources that are bound to a given Network Slice,</t> <t>tracing resources that are bound to a given Network Slice,</t>
</li> </li>
<li> <li>
<t>tracing resources that are invoked when forwarding a given flow bound to a given Network Slice,</t> <t>tracing resources that are invoked when forwarding a given flow bound to a given Network Slice,</t>
</li> </li>
<li> <li>
<t>assessing whether flow isolation characteristics are in <t>assessing whether flow isolation characteristics are in
conformance with the Network Slice Service requirements, or</t> conformance with the Network Slice Service requirements, or</t>
</li> </li>
<li> <li>
<t>assessing the compliance of the allocated Network Slice resourc <t>assessing the compliance of the allocated Network Slice resourc
es against flow/ es against flow and customer service requirements.</t>
customer service requirements.</t>
</li> </li>
</ul> </ul>
<t> <t>
<xref target="RFC7276"/> provides an overview of available OAM <xref target="RFC7276"/> provides an overview of available OAM
tools. These technology-specific tools can be reused in the context tools. These technology-specific tools can be reused in the context
of network slicing. Providers that deploy network slicing of network slicing. Providers that deploy network slicing
capabilities should be able to select whatever OAM technology or specific featur e that would address their needs.</t> capabilities should be able to select whatever OAM technology or specific featur e that would address their needs.</t>
</li> </li>
<li> <li>
<t>Providers may want to enable differentiated failure <t>Providers may want to enable differentiated failure
detect and repair features for a subset of network detection and repair features for a subset of network
slices. For example, a given Network Slice may require fast detect and slices. For example, a given Network Slice may require fast detection and
repair mechanisms, while others may repair mechanisms, while others may
not be engineered with such means. The provider can use not be engineered with such means. The provider can use
techniques such as <xref target="RFC5286"/>, <xref target="RFC5714"/>, or <xref target="RFC8355"/>.</t> techniques such as those described in <xref target="RFC5286"/>, <xref target="RF C5714"/>, and <xref target="RFC8355"/>.</t>
</li> </li>
<li> <li>
<t>Providers may deploy means to dynamically discover the set of Netwo rk Slices that <t>Providers may deploy means to dynamically discover the set of Netwo rk Slices that
are enabled within its network. Such dynamic discovery capability are enabled within its network. Such dynamic discovery capability
facilitates the detection of any mismatch between the view facilitates the detection of any mismatch between the view
maintained by the control/management plane and the actual network maintained by the control/management plane and the actual network
configuration. When mismatches are detected, corrective actions configuration. When mismatches are detected, corrective actions
should be undertaken accordingly. For example, a provider may rely should be undertaken accordingly. For example, a provider may rely
upon the L3NM <xref target="RFC9182"/> or the L2NM <xref target="RFC9291"/> to m aintain the full upon the L3NM <xref target="RFC9182"/> or the L2NM <xref target="RFC9291"/> to m aintain the full
set of L3VPN/L2VPNs that are used to deliver Network Slice Services. set of L3VPN/L2VPNs that are used to deliver Network Slice Services.
The correlation between an LxVPN instance and a Network Slice Service The correlation between an LxVPN instance and a Network Slice Service
is maintained using "parent-service-id" attribute (<xref section="7.3" sectionFo rmat="of" target="RFC9182"/>).</t> is maintained using the "parent-service-id" attribute (<xref section="7.3" secti onFormat="of" target="RFC9182"/>).</t>
</li> </li>
<li> <li>
<t>Means to report a set of network performance metrics to assess <!-- [rfced] FYI - We updated this sentence as follows. Let us know any
whether the agreed slice service objectives are honored. These means are used fo concerns.
r SLO monitoring and violation detect purposes. For example,
<xref target="RFC9375"/> can be used to report links' one-way delay, Original:
one-way delay variation, etc. Both conventional active/passive For example, [RFC9375] can be used to report links' one-way delay,
one-way delay variation, etc.
Perhaps:
For example, the YANG data model in [RFC9375] can be used to report
the one-way delay and one-way delay variation of links.
-->
<t>The means to report a set of network performance metrics to assess
whether the agreed slice service objectives are honored. These means are used fo
r SLO monitoring and violation detection purposes. For example,
the YANG data model in <xref target="RFC9375"/> can be used to report the one-wa
y delay and
one-way delay variation of links. Both conventional active/passive
measurement methods <xref target="RFC7799"/> and more recent telemetry methods measurement methods <xref target="RFC7799"/> and more recent telemetry methods
(e.g., YANG Push <xref target="RFC8641"/>) can be used.</t> (e.g., YANG Push <xref target="RFC8641"/>) can be used.</t>
</li> </li>
<li> <li>
<t>Means to report and expose observed performance metrics and other O
AM state to customer. <!-- [rfced] The top-level bullets in the list in Section 8 are all complete
For example, <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> exposes sentences except for the items below. How may we revise these to create
a set of statistics per SDP, connectivity construct, and connection group.</t> complete sentences?
Original:
* Means to report a set of network performance metrics to assess
whether the agreed slice service objectives are honored.
...
* Means to report and expose observed performance metrics and other
OAM state to customer.
Perhaps:
* Providers should provide the means to report a set of network
performance metrics to assess whether the agreed slice service objectives
are honored.
...
* Providers should have the means to report and expose observed performance
metrics and other OAM state to customer.
-->
<t>The means to report and expose observed performance metrics and oth
er OAM state to customer.
For example, the YANG data model defined in <xref target="I-D.ietf-teas-ietf-net
work-slice-nbi-yang"/> exposes a set of statistics per SDP, connectivity constru
ct, and connection group.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sec-sca-impli"> <section anchor="sec-sca-impli">
<name>Scalability Implications</name> <name>Scalability Implications</name>
<t>The mapping between 5G slice to TN slices (see <xref target="sec-mappin <!-- [rfced] The last two sentences mention 1-to-1 mapping and N-to-1
g"/>) is a design choice of service operators that may be a function of, e.g., t mapping, but these are not listed in Section 3.5 (which only lists 1 to
he number of instantiated slices, requested services, or local engineering capab N, M to 1, and M to N). Please review and let us know if any updates are
ilities and guidelines. However, operators should carefully consider means to ea needed. (The first two sentences are included for context.)
se slice migration strategies. For example, a provider may initially adopt a 1-t
o-1 mapping if it has to instantiate just a few Network Slices and accommodate t Original:
he need of only a few customers. That provider may decide to move to an N-to-1 m The mapping between 5G slice to TN slices (see Section 3.5) is a
apping for aggregation/scalability purposes if sustained increased slice demand design choice of service operators that may be a function of, e.g.,
is observed.</t> the number of instantiated slices, requested services, or local
<t>Putting in place adequate automation means to realize Network Slices (i engineering capabilities and guidelines. However, operators should
ncluding the adjustment of Slice Services to Network Slices mapping) would ease carefully consider means to ease slice migration strategies. For
slice migration operations.</t> example, a provider may initially adopt a 1-to-1 mapping if it has to
<t>The realization model described in the document inherits the scalabilit instantiate just a few Network Slices and accommodate the need of
y properties of the underlying L2VPN and L3VPN technologies (<xref target="sec-o only a few customers. That provider may decide to move to an N-to-1
ver-rea-model"/>). Readers may refer, for example, to <xref section="13" section mapping for aggregation/scalability purposes if sustained increased
Format="of" target="RFC4365"/> or <xref section="1.2.5" sectionFormat="of" targe slice demand is observed.
t="RFC6624"/> for a scalability assessment of some of these technologies. Provid -->
ers may adjust the mapping model to better handle local scalability constraints.
</t> <t>The mapping of 5G slices to TN slices (see <xref target="sec-mapping"/>
) is a design choice of service operators that may be a function of, e.g., the n
umber of instantiated slices, requested services, or local engineering capabilit
ies and guidelines. However, operators should carefully consider means to ease s
lice migration strategies. For example, a provider may initially adopt a 1-to-1
mapping if it has to instantiate just a few Network Slices and accommodate the n
eed of only a few customers. That provider may decide to move to an N-to-1 mappi
ng for aggregation/scalability purposes if sustained increased slice demand is o
bserved.</t>
<t>Putting in place adequate automation means to realize Network Slices (i
ncluding the adjustment of the mapping of Slice Services to Network Slices) woul
d ease slice migration operations.</t>
<t>The realization model described in this document inherits the scalabili
ty properties of the underlying L2VPN and L3VPN technologies (<xref target="sec-
over-rea-model"/>). Readers may refer, for example, to <xref section="13" sectio
nFormat="of" target="RFC4365"/> or <xref section="1.2.5" sectionFormat="of" targ
et="RFC6624"/> for a scalability assessment of some of these technologies. Provi
ders may adjust the mapping model to better handle local scalability constraints
.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document does not make any IANA request.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref section="10" sectionFormat="of" target="RFC9543"/> discusses gene ric security considerations that are applicable to network slicing, with a focus on the following considerations:</t> <t><xref section="10" sectionFormat="of" target="RFC9543"/> discusses gene ric security considerations that are applicable to network slicing, with a focus on the following considerations:</t>
<dl> <dl newline="true">
<dt>Conformance to security constraints:</dt> <dt>Conformance to security constraints:</dt>
<dd> <dd>
<t>Specific security requests, such as not routing traffic through a p <t>Specific security requests, such as not routing traffic through a
articular geographical region can be met by mapping the traffic to an underlay t particular geographical region can be met by mapping the traffic to
ransport (<xref target="transport-plane-mapping-models"/>) that avoids that regi an underlay transport (<xref
on.</t> target="transport-plane-mapping-models"/>) that avoids that
region.</t>
</dd> </dd>
<dt>NSC authentication:</dt> <dt>NSC authentication:</dt>
<dd> <dd>
<t>Per <xref target="RFC9543"/>, this is about underlay networks need <t>Per <xref target="RFC9543"/>, underlay networks
to be protected against attacks from an adversary NSC as this could destabilize need to be protected against attacks from an adversary NSC as this
overall network operations. The interaction between an NSC and the underly netwo could destabilize overall network operations. The interaction
rk is used to pass service provisioning requests following a set of YANG modules between an NSC and the underlay network is used to pass service
that are designed to be accessed via YANG-based management protocols, such as provisioning requests following a set of YANG modules that are
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These YA designed to be accessed via YANG-based management protocols, such as
NG-based management protocols (1) have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ target="RFC8040"/>. These YANG-based management protocols have
et="RFC8446"/>, and to use (1) a secure transport layer (e.g., SSH <xref target="RFC4252"/
QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.</t> >,
</dd> TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and
<dt/> (2) mutual authentication.</t>
<dd> <t>The NETCONF access control model <xref target="RFC8341"/>
<t>The NETCONF access control model <xref target="RFC8341"/> provides provides the means to restrict access for particular NETCONF or
the means to restrict access for particular NETCONF or RESTCONF users to a preco RESTCONF users to a preconfigured subset of all available NETCONF or
nfigured subset of all available NETCONF or RESTCONF protocol operations and con RESTCONF protocol operations and content.</t>
tent.</t> <t>Readers may refer to documents that describe NSC realization, such
</dd> as <xref target="I-D.ietf-teas-ns-controller-models"/>.</t>
<dt/>
<dd>
<t>Readers may refer to documents that describe NSC realization such a
s <xref target="I-D.ietf-teas-ns-controller-models"/>.</t>
</dd> </dd>
<dt>Specific isolation criteria:</dt> <dt>Specific isolation criteria:</dt>
<dd> <dd>
<t>Adequate admission control policies, for example policers as descri <t>Adequate admission control policies, for example, policers as
bed in <xref target="sec-inbound-edge-resource-control"/>, should be configured described in <xref target="sec-inbound-edge-resource-control"/>,
in the edge of the provider network to control access to specific slice resource should be configured in the edge of the provider network to control
s. This prevents the possibility of one slice consuming resources at the expense access to specific slice resources. This prevents the possibility of
of other slices. Likewise, access to classification and mapping tables have to one slice consuming resources at the expense of other
be controlled to prevent misbehaviors (an unauthorized entity may modify the tab slices. Likewise, access to classification and mapping tables have
le to bind traffic to a random slice, redirect the traffic, etc.). Network devic to be controlled to prevent misbehaviors (an unauthorized entity may
es have to check that a required access privilege is provided before granting ac modify the table to bind traffic to a random slice, redirect the
cess to specific data or performing specific actions.</t> traffic, etc.). Network devices have to check that a required access
privilege is provided before granting access to specific data or
performing specific actions.</t>
</dd> </dd>
<dt>Data Confidentiality and Integrity of an IETF Network Slice:</dt> <dt>Data Confidentiality and Integrity of an IETF Network Slice:</dt>
<dd> <dd>
<t>As described in <xref section="5.1.2.1" sectionFormat="of" target=" <t>As described in <xref section="5.1.2.1" sectionFormat="of"
RFC9543"/>, the customer might request a Service Level Expectation (SLE) that ma target="RFC9543"/>, the customer might request a Service Level
ndates encryption.</t> Expectation (SLE) that mandates encryption.</t>
</dd> <t>This can be achieved, e.g., by mapping the traffic to an underlay
<dt/> transport (<xref target="transport-plane-mapping-models"/>) that
<dd> uses only MACsec-encrypted links.</t>
<t>This can be achieved, e.g., by mapping the traffic to an underlay t
ransport (<xref target="transport-plane-mapping-models"/>) that uses only MACsec
-encrypted links.</t>
</dd> </dd>
</dl> </dl>
<t>In order to avoid the need for a mapping table to associate source/dest ination IP <t>In order to avoid the need for a mapping table to associate source/dest ination IP
addresses and slices' specific S-NSSAIs, <xref target="sec-ip-hof"/> describes a n approach where some or all S-NSSAI bits addresses and the specific S-NSSAIs of slices, <xref target="sec-ip-hof"/> descr ibes an approach where some or all S-NSSAI bits
are embedded in an IPv6 address using an algorithm approach. An attacker from wi thin the transport network are embedded in an IPv6 address using an algorithm approach. An attacker from wi thin the transport network
who has access to the mapping configuration may infer the slices to which belong who has access to the mapping configuration may infer the slices to which a pack
a packet. It may also et belongs. It may also
alter these bits which may lead to steering the packet via a distinct network sl alter these bits, which may lead to steering the packet via a distinct network s
ice, and thus lead to lice and thus to
service disruption. Note that such an attacker from within the transport network may inflict more damage (e.g., randomly drop packets).</t> service disruption. Note that such an attacker from within the transport network may inflict more damage (e.g., randomly drop packets).</t>
<t>Security considerations specific to each of the technologies and protoc ols listed in the document are discussed in the specification documents of each of these protocols. In particular, readers should refer to the "Security Framewo rk for Provider-Provisioned Virtual Private Networks (PPVPNs)" <xref target="RFC 4111"/>, the "Applicability Statement for BGP/MPLS IP Virtual Private Networks ( VPNs)" (<xref section="6" sectionFormat="of" target="RFC4365"/>), and the "Analy sis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)" <xref target ="RFC4381"/> for a comprehensive discussion about security considerations relate d to VPN technologies (including authentication and encryption between PEs, use of IPsec tunnels that terminate within the customer sites to protect user data, prevention of illegitimate traffic from entering a VPN instance, etc.). Also, re aders may refer to <xref section="9" sectionFormat="of" target="RFC9522"/> for a discussion about security considerations related to TE mechanisms.</t> <t>Security considerations specific to each of the technologies and protoc ols listed in the document are discussed in the specification documents of each of these protocols. In particular, readers should refer to the "Security Framewo rk for Provider-Provisioned Virtual Private Networks (PPVPNs)" <xref target="RFC 4111"/>, the "Applicability Statement for BGP/MPLS IP Virtual Private Networks ( VPNs)" (<xref section="6" sectionFormat="of" target="RFC4365"/>), and the "Analy sis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)" <xref target ="RFC4381"/> for a comprehensive discussion about security considerations relate d to VPN technologies (including authentication and encryption between PEs, use of IPsec tunnels that terminate within the customer sites to protect user data, prevention of illegitimate traffic from entering a VPN instance, etc.). Also, re aders may refer to <xref section="9" sectionFormat="of" target="RFC9522"/> for a discussion about security considerations related to TE mechanisms.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.cbs-teas-5qi-to-dscp-mapping" to="MAPPING"/>
<displayreference target="I-D.ietf-teas-5g-network-slice-application" to="NS-APP
"/>
<displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="NSSM"/>
<displayreference target="I-D.ietf-teas-ns-controller-models" to="NSC-MODEL"/>
<displayreference target="I-D.ietf-teas-ns-ip-mpls" to="NS-IP-MPLS"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9543"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 543.xml"/>
<title>A Framework for Network Slices in Networks Built from IETF Te <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
chnologies</title> 364.xml"/>
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
rrel"/> 608.xml"/>
<author fullname="J. Drake" initials="J." role="editor" surname="Dra <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ke"/> 341.xml"/>
<author fullname="R. Rokui" initials="R." surname="Rokui"/>
<author fullname="S. Homma" initials="S." surname="Homma"/>
<author fullname="K. Makhijani" initials="K." surname="Makhijani"/>
<author fullname="L. Contreras" initials="L." surname="Contreras"/>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<date month="March" year="2024"/>
<abstract>
<t>This document describes network slicing in the context of netwo
rks built from IETF technologies. It defines the term "IETF Network Slice" to de
scribe this type of network slice and establishes the general principles of netw
ork slicing in the IETF context.</t>
<t>The document discusses the general framework for requesting and
operating IETF Network Slices, the characteristics of an IETF Network Slice, th
e necessary system components and interfaces, and the mapping of abstract reques
ts to more specific technologies. The document also discusses related considerat
ions with monitoring and security.</t>
<t>This document also provides definitions of related terms to ena
ble consistent usage in other IETF documents that describe or use aspects of IET
F Network Slices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9543"/>
<seriesInfo name="DOI" value="10.17487/RFC9543"/>
</reference>
<reference anchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes a method by which a Service Provider ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. This method uses a "peer model", in which the customers' edge routers (CE
routers) send their routes to the Service Provider's edge routers (PE routers);
there is no "overlay" visible to the customer's routing algorithm, and CE router
s at different sites do not peer with each other. Data packets are tunneled thro
ugh the backbone, so that the core routers do not need to know the VPN routes. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364"/>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
</reference>
<reference anchor="RFC7608">
<front>
<title>IPv6 Prefix Length Recommendation for Forwarding</title>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<author fullname="A. Petrescu" initials="A." surname="Petrescu"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<date month="July" year="2015"/>
<abstract>
<t>IPv6 prefix length, as in IPv4, is a parameter conveyed and use
d in IPv6 routing and forwarding processes in accordance with the Classless Inte
r-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any nu
mber from zero to 128, although subnets using stateless address autoconfiguratio
n (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and s
oftware implementations of routing and forwarding should therefore impose no rul
es on prefix length, but implement longest-match-first on prefixes of any valid
length.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="198"/>
<seriesInfo name="RFC" value="7608"/>
<seriesInfo name="DOI" value="10.17487/RFC7608"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<!-- [rfced] FYI, we updated the title for this reference to match the title
at the URL. Please let us know if you prefer otherwise.
Original:
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "5G Mobile
Networks: A Systems Approach", 2022,
<https://5g.systemsapproach.org/>.
Current:
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "Private 5G: A
Systems Approach", 2023,
<https://5g.systemsapproach.org/>.
-->
<reference anchor="Book-5G" target="https://5g.systemsapproach.org/"> <reference anchor="Book-5G" target="https://5g.systemsapproach.org/">
<front> <front>
<title>5G Mobile Networks: A Systems Approach</title> <title>Private 5G: A Systems Approach</title>
<author fullname="Larry Peterson"> <author fullname="Larry Peterson">
<organization/> <organization/>
</author> </author>
<author fullname="Oguz Sunay"> <author fullname="Oguz Sunay">
<organization/> <organization/>
</author> </author>
<author fullname="Bruce Davie"> <author fullname="Bruce Davie">
<organization/> <organization/>
</author> </author>
<date year="2022"/> <date year="2023"/>
</front> </front>
</reference> </reference>
<!-- [rfced] Would it be helpful to point to specific versions of [TS-23.501]
and [TS-28.530]? The original date for both references was 2024, but
there are multiple versions across multiple releases from that year, and
both also have new 2025 versions.
Note that specific sections and figures in [TS-28.530] are mentioned in the
text. We are not sure if these will be stable across versions.
Current:
[TS-23.501]
3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
...
[TS-28.530]
3GPP, "Management and orchestration; Concepts, use cases
and requirements", 3GPP TS 28.530,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3273>.
-->
<reference anchor="TS-23.501" target="https://portal.3gpp.org/desktopmod ules/Specifications/SpecificationDetails.aspx?specificationId=3144"> <reference anchor="TS-23.501" target="https://portal.3gpp.org/desktopmod ules/Specifications/SpecificationDetails.aspx?specificationId=3144">
<front> <front>
<title>TS 23.501: System architecture for the 5G System (5GS)</title > <title>System architecture for the 5G System (5GS)</title>
<author> <author>
<organization>3GPP</organization> <organization abbrev="3GPP">3rd Generation Partnership Project</or ganization>
</author> </author>
<date year="2024"/>
</front> </front>
<seriesInfo name="3GPP TS" value="23.501"/>
</reference> </reference>
<reference anchor="TS-28.530" target="https://portal.3gpp.org/desktopmod ules/Specifications/SpecificationDetails.aspx?specificationId=3273"> <reference anchor="TS-28.530" target="https://portal.3gpp.org/desktopmod ules/Specifications/SpecificationDetails.aspx?specificationId=3273">
<front> <front>
<title>TS 28.530: Management and orchestration; Concepts, use cases and requirements)</title> <title>Management and orchestration; Concepts, use cases and require ments</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year="2024"/>
</front> </front>
<!-- 28.530 -->
<seriesInfo name="3GPP TS" value=""/>
</reference> </reference>
<reference anchor="O-RAN.WG9.XPSAAS" target="https://www.o-ran.org/speci
fications"> <!-- [rfced] The current URL for this reference
(https://www.o-ran.org/specifications) goes to a page titled "O-RAN
Specifications". We were able to find a list of O-RAN specifications here:
https://specifications.o-ran.org/specifications.
We were unable to find Version 04.00 of the O-RAN specification. It
appears that this page only has the most recent version - Version
08.00 - published in June 2024. May we update this reference
accordingly to point to this version?
Original:
[O-RAN.WG9.XPSAAS]
O-RAN Alliance, "O-RAN.WG9.XPSAAS: O-RAN WG9 Xhaul Packet
Switched Architectures and Solutions Version 04.00", March
2023, <https://www.o-ran.org/specifications>.
Perhaps:
[O-RAN.WG9.XPSAAS]
O-RAN Alliance, "Xhaul Packet Switched Architectures and
Solutions", O-RAN.WG9.XPSAAS, Version 08.00, June 2024,
<https://specifications.o-ran.org/specifications>.
-->
<reference anchor="O-RAN.WG9.XPSAAS" target="https://specifications.o-ra
n.org/specifications">
<front> <front>
<title>O-RAN.WG9.XPSAAS: O-RAN WG9 Xhaul Packet Switched Architectur es and Solutions Version 04.00</title> <title>Xhaul Packet Switched Architectures and Solutions</title>
<author> <author>
<organization>O-RAN Alliance</organization> <organization>O-RAN Alliance</organization>
</author> </author>
<date year="2023" month="March"/> <date year="2023" month="March"/>
</front> </front>
<refcontent>O-RAN.WG9.XPSAAS, Version 04.00</refcontent>
</reference> </reference>
<reference anchor="NG.113" target="https://www.gsma.com/newsroom/wp-cont ent/uploads//NG.113-v4.0.pdf"> <reference anchor="NG.113" target="https://www.gsma.com/newsroom/wp-cont ent/uploads//NG.113-v4.0.pdf">
<front> <front>
<title>NG.113: 5GS Roaming Guidelines Version 4.0</title> <title>NG.113: 5GS Roaming Guidelines</title>
<author> <author>
<organization>GSMA</organization> <organization>GSMA</organization>
</author> </author>
<date year="2021" month="May"/> <date year="2021" month="May"/>
</front> </front>
<refcontent>Version 4.0</refcontent>
</reference> </reference>
<reference anchor="IEEE802.1AE" target="https://1.ieee802.org/security/8 02-1ae/"> <reference anchor="IEEE802.1AE" target="https://1.ieee802.org/security/8 02-1ae/">
<front> <front>
<title>802.1AE: MAC Security (MACsec)</title> <title>802.1AE: MAC Security (MACsec)</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="ECPRI" target="https://www.cpri.info/downloads/eCPRI_ v_2.0_2019_05_10c.pdf"> <reference anchor="ECPRI" target="https://www.cpri.info/downloads/eCPRI_ v_2.0_2019_05_10c.pdf">
<front> <front>
<title>Common Public Radio Interface: eCPRI Interface Specification< /title> <title>Common Public Radio Interface: eCPRI Interface Specification< /title>
<author> <author>
<organization>Common Public Radio Interface</organization> <organization>Common Public Radio Interface</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-teas-5g-network-slice-application"> <!-- [I-D.ietf-teas-5g-network-slice-application]
<front> draft-ietf-teas-5g-network-slice-application-05
<title>IETF Network Slice Application in 3GPP 5G End-to-End Network IESG State: I-D Exists as of 10/3/25
Slice</title> Long Way
<author fullname="Xuesong Geng" initials="X." surname="Geng"> -->
<organization>Huawei Technologies</organization>
</author>
<author fullname="Luis M. Contreras" initials="L. M." surname="Contr
eras">
<organization>Telefonica</organization>
</author>
<author fullname="Reza Rokui" initials="R." surname="Rokui">
<organization>Ciena</organization>
</author>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Ivan Bykov" initials="I." surname="Bykov">
<organization>Ribbon Communications</organization>
</author>
<date day="3" month="March" year="2025"/>
<abstract>
<t> Network Slicing is one of the core features of 5G defined in
3GPP,
which provides different network service as independent logical
networks. To provide 5G network slices services, an end-to-end
network slice has to span three network segments: Radio Access
Network (RAN), Mobile Core Network (CN) and Transport Network (TN).
This document describes the application of the IETF network slice
framework in providing 5G end-to-end network slices, including
network slice mapping in the management, control and data planes.
</t> <reference anchor="I-D.ietf-teas-5g-network-slice-application" target="https://d
</abstract> atatracker.ietf.org/doc/html/draft-ietf-teas-5g-network-slice-application-05">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-5g-network-sl <title>IETF Network Slice Application in 3GPP 5G End-to-End Network Slice<
ice-application-04"/> /title>
</reference> <author initials="X." surname="Geng" fullname="Xuesong Geng">
<reference anchor="I-D.ietf-teas-ns-ip-mpls"> <organization>Huawei Technologies</organization>
<front> </author>
<title>Realizing Network Slices in IP/MPLS Networks</title> <author initials="L. M." surname="Contreras" fullname="Luis M. Contreras"
<author fullname="Tarek Saad" initials="T." surname="Saad"> role="editor">
<organization>Cisco Systems Inc.</organization> <organization>Telefonica</organization>
</author> </author>
<author fullname="Vishnu Pavan Beeram" initials="V. P." surname="Bee <author initials="R." surname="Rokui" fullname="Reza Rokui">
ram"> <organization>Ciena</organization>
<organization>Juniper Networks</organization> </author>
</author> <author initials="J." surname="Dong" fullname="Jie Dong">
<author fullname="Jie Dong" initials="J." surname="Dong"> <organization>Huawei Technologies</organization>
<organization>Huawei Technologies</organization> </author>
</author> <author initials="I." surname="Bykov" fullname="Ivan Bykov">
<author fullname="Joel M. Halpern" initials="J. M." surname="Halpern <organization>Ribbon Communications</organization>
"> </author>
<organization>Ericsson</organization> <date month="July" day="7" year="2025" />
</author> </front>
<author fullname="Shaofu Peng" initials="S." surname="Peng"> <seriesInfo name="Internet-Draft" value="draft-ietf-teas-5g-network-slice-app
<organization>ZTE Corporation</organization> lication-05" />
</author>
<date day="2" month="March" year="2025"/>
<abstract>
<t> Realizing network slices may require the Service Provider to
have the
ability to partition a physical network into multiple logical
networks of varying sizes, structures, and functions so that each
slice can be dedicated to specific services or customers. Multiple
network slices can be realized on the same network while ensuring
slice elasticity in terms of network resource allocation. This
document describes a scalable solution to realize network slicing in
IP/MPLS networks by supporting multiple services on top of a single
physical network by relying on compliant domains and nodes to provide
forwarding treatment (scheduling, drop policy, resource usage) on to
packets that carry identifiers that indicate the slicing service that
is to be applied to the packets.
</t> </reference>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ns-ip-mpls-05
"/>
</reference>
<reference anchor="RFC4664">
<front>
<title>Framework for Layer 2 Virtual Private Networks (L2VPNs)</titl
e>
<author fullname="L. Andersson" initials="L." role="editor" surname=
"Andersson"/>
<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
en"/>
<date month="September" year="2006"/>
<abstract>
<t>This document provides a framework for Layer 2 Provider Provisi
oned Virtual Private Networks (L2VPNs). This framework is intended to aid in sta
ndardizing protocols and mechanisms to support interoperable L2VPNs. This memo p
rovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4664"/>
<seriesInfo name="DOI" value="10.17487/RFC4664"/>
</reference>
<reference anchor="RFC8986">
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="P. Camarillo" initials="P." role="editor" surname=
"Camarillo"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="February" year="2021"/>
<abstract>
<t>The Segment Routing over IPv6 (SRv6) Network Programming framew
ork enables a network operator or an application to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet header.</t>
<t>Each instruction is implemented on one or several nodes in the
network and identified by an SRv6 Segment Identifier in the packet.</t>
<t>This document defines the SRv6 Network Programming concept and
specifies the base set of SRv6 behaviors that enables the creation of interopera
ble overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
<reference anchor="I-D.ietf-opsawg-teas-attachment-circuit">
<front>
<title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-S
ervice (ACaaS)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="January" year="2025"/>
<abstract>
<t> Delivery of network services assumes that appropriate setup
is
provisioned over the links that connect customer termination points
and a provider network. The required setup to allow successful data
exchange over these links is referred to as an attachment circuit
(AC), while the underlying link is referred to as "bearer".
This document specifies a YANG service data model for ACs. This <!-- [I-D.ietf-teas-ns-ip-mpls]
model can be used for the provisioning of ACs before or during draft-ietf-teas-ns-ip-mpls-05
service provisioning (e.g., Network Slice Service). IESG State: I-D Exists as of 06/23/25
Long Way
-->
<reference anchor="I-D.ietf-teas-ns-ip-mpls" target="https://datatracker.ietf.or
g/doc/html/draft-ietf-teas-ns-ip-mpls-05">
<front>
<title>Realizing Network Slices in IP/MPLS Networks</title>
<author fullname="Tarek Saad" initials="T." surname="Saad">
<organization>Cisco Systems Inc.</organization>
</author>
<author fullname="Vishnu Pavan Beeram" initials="V." surname="Beeram">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Joel M. Halpern" initials="J." surname="Halpern">
<organization>Ericsson</organization>
</author>
<author fullname="Shaofu Peng" initials="S." surname="Peng">
<organization>ZTE Corporation</organization>
</author>
<date day="2" month="March" year="2025"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ns-ip-mpls-05"/>
</reference>
The document also specifies a YANG service model for managing bearers <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
over which ACs are established. 664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
</t> <!-- [I-D.ietf-opsawg-teas-attachment-circuit]
</abstract> Published as RFC 9834
</front> -->
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attach
ment-circuit-20"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ntw-attachment-circuit">
<front>
<title>A Network YANG Data Model for Attachment Circuits</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Richard Roberts" initials="R." surname="Roberts">
<organization>Juniper</organization>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O. G." surname="
de Dios">
<organization>Telefonica</organization>
</author>
<author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="January" year="2025"/>
<abstract>
<t> This document specifies a network model for attachment circu
its. The
model can be used for the provisioning of attachment circuits prior
or during service provisioning (e.g., VPN, Network Slice Service). A
companion service model is specified in the YANG Data Models for
Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf-
opsawg-teas-attachment-circuit).
The module augments the base network ('ietf-network') and the Service <!-- [I-D.ietf-opsawg-ntw-attachment-circuit]
Attachment Point (SAP) models with the detailed information for the Published as RFC 9835
provisioning of attachment circuits in Provider Edges (PEs). -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
834.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
835.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 969.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachm
ent-circuit-16"/>
</reference>
<reference anchor="RFC8969">
<front>
<title>A Framework for Automating Service and Network Management wit
h YANG</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Geng" initials="L." surname="Geng"/>
<date month="January" year="2021"/>
<abstract>
<t>Data models provide a programmatic approach to represent servic
es and networks. Concretely, they can be used to derive configuration informatio
n for network and service components, and state information that will be monitor
ed and tracked. Data models can be used during the service and network managemen
t life cycle (e.g., service instantiation, service provisioning, service optimiz
ation, service monitoring, service diagnosing, and service assurance). Data mode
ls are also instrumental in the automation of network management, and they can p
rovide closed-loop control for adaptive and deterministic service creation, deli
very, and maintenance.</t>
<t>This document describes a framework for service and network man
agement automation that takes advantage of YANG modeling technologies. This fram
ework is drawn from a network operator perspective irrespective of the origin of
a data model; thus, it can accommodate YANG modules that are developed outside
the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8969"/>
<seriesInfo name="DOI" value="10.17487/RFC8969"/>
</reference>
<reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang">
<front>
<title>A YANG Data Model for the RFC 9543 Network Slice Service</tit
le>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Reza Rokui" initials="R." surname="Rokui">
<organization>Ciena</organization>
</author>
<author fullname="Tarek Saad" initials="T." surname="Saad">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="John Mullooly" initials="J." surname="Mullooly">
<organization>Cisco Systems, Inc</organization>
</author>
<date day="8" month="February" year="2025"/>
<abstract>
<t> This document defines a YANG data model for RFC 9543 Network
Slice
Service. The model can be used in the Network Slice Service
interface between a customer and a provider that offers RFC 9543
Network Slice Services.
</t> <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang]
</abstract> draft-ietf-teas-ietf-network-slice-nbi-yang-25
</front> IESG State: RFC Ed Queue (MISSREF) as of 06/23/25
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network- -->
slice-nbi-yang-22"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> ietf-teas-ietf-network-slice-nbi-yang.xml"/>
<reference anchor="RFC4761"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 761.xml"/>
<title>Virtual Private LAN Service (VPLS) Using BGP for Auto-Discove <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
ry and Signaling</title> 762.xml"/>
<author fullname="K. Kompella" initials="K." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
Kompella"/> 214.xml"/>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ekhter"/> 623.xml"/>
<date month="January" year="2007"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 432.xml"/>
<t>Virtual Private LAN Service (VPLS), also known as Transparent L <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
AN Service and Virtual Private Switched Network service, is a useful Service Pro 365.xml"/>
vider offering. The service offers a Layer 2 Virtual Private Network (VPN); howe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ver, in the case of VPLS, the customers in the VPN are connected by a multipoint 522.xml"/>
Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point i <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
n nature.</t> 026.xml"/>
<t>This document describes the functions required to offer VPLS, a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a p 176.xml"/>
acket switched network. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</abstract> 136.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="4761"/> 422.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC4761"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</reference> 510.xml"/>
<reference anchor="RFC4762"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 360.xml"/>
<title>Virtual Private LAN Service (VPLS) Using Label Distribution P <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
rotocol (LDP) Signaling</title> 997.xml"/>
<author fullname="M. Lasserre" initials="M." role="editor" surname="
Lasserre"/>
<author fullname="V. Kompella" initials="V." role="editor" surname="
Kompella"/>
<date month="January" year="2007"/>
<abstract>
<t>This document describes a Virtual Private LAN Service (VPLS) so
lution using pseudowires, a service previously implemented over other tunneling
technologies and known as Transparent LAN Services (TLS). A VPLS creates an emul
ated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast
domain that is fully capable of learning and forwarding on Ethernet MAC addresse
s and that is closed to a given set of users. Multiple VPLS services can be supp
orted from a single Provider Edge (PE) node.</t>
<t>This document describes the control plane functions of signalin
g pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447.
It is agnostic to discovery protocols. The data plane functions of forwarding a
re also described, focusing in particular on the learning of MAC addresses. The
encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4762"/>
<seriesInfo name="DOI" value="10.17487/RFC4762"/>
</reference>
<reference anchor="RFC8214">
<front>
<title>Virtual Private Wire Service Support in Ethernet VPN</title>
<author fullname="S. Boutros" initials="S." surname="Boutros"/>
<author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
<author fullname="S. Salam" initials="S." surname="Salam"/>
<author fullname="J. Drake" initials="J." surname="Drake"/>
<author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
<date month="August" year="2017"/>
<abstract>
<t>This document describes how Ethernet VPN (EVPN) can be used to
support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomp
lishes the following for VPWS: provides Single-Active as well as All-Active mult
ihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW)
signaling, and provides fast protection convergence upon node or link failure.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="8214"/>
<seriesInfo name="DOI" value="10.17487/RFC8214"/>
</reference>
<reference anchor="RFC7623">
<front>
<title>Provider Backbone Bridging Combined with Ethernet VPN (PBB-EV
PN)</title>
<author fullname="A. Sajassi" initials="A." role="editor" surname="S
ajassi"/>
<author fullname="S. Salam" initials="S." surname="Salam"/>
<author fullname="N. Bitar" initials="N." surname="Bitar"/>
<author fullname="A. Isaac" initials="A." surname="Isaac"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<date month="September" year="2015"/>
<abstract>
<t>This document discusses how Ethernet Provider Backbone Bridging
(PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of
BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) address
es via Provider Backbone MAC (B-MAC) address, provide client MAC address mobilit
y using C-MAC aggregation, confine the scope of C-MAC learning to only active fl
ows, offer per-site policies, and avoid C-MAC address flushing on topology chang
es. The combined solution is referred to as PBB-EVPN.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7623"/>
<seriesInfo name="DOI" value="10.17487/RFC7623"/>
</reference>
<reference anchor="RFC7432">
<front>
<title>BGP MPLS-Based Ethernet VPN</title>
<author fullname="A. Sajassi" initials="A." role="editor" surname="S
ajassi"/>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
<author fullname="N. Bitar" initials="N." surname="Bitar"/>
<author fullname="A. Isaac" initials="A." surname="Isaac"/>
<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
<author fullname="J. Drake" initials="J." surname="Drake"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<date month="February" year="2015"/>
<abstract>
<t>This document describes procedures for BGP MPLS-based Ethernet
VPNs (EVPN). The procedures described here meet the requirements specified in RF
C 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7432"/>
<seriesInfo name="DOI" value="10.17487/RFC7432"/>
</reference>
<reference anchor="RFC8365">
<front>
<title>A Network Virtualization Overlay Solution Using Ethernet VPN
(EVPN)</title>
<author fullname="A. Sajassi" initials="A." role="editor" surname="S
ajassi"/>
<author fullname="J. Drake" initials="J." role="editor" surname="Dra
ke"/>
<author fullname="N. Bitar" initials="N." surname="Bitar"/>
<author fullname="R. Shekhar" initials="R." surname="Shekhar"/>
<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<date month="March" year="2018"/>
<abstract>
<t>This document specifies how Ethernet VPN (EVPN) can be used as
a Network Virtualization Overlay (NVO) solution and explores the various tunnel
encapsulation options over IP and their impact on the EVPN control plane and pro
cedures. In particular, the following encapsulation options are analyzed: Virtua
l Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsula
tion (NVGRE), and MPLS over GRE. This specification is also applicable to Generi
c Network Virtualization Encapsulation (GENEVE); however, some incremental work
is required, which will be covered in a separate document. This document also sp
ecifies new multihoming procedures for split-horizon filtering and mass withdraw
al. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations an
d Autonomous System Border Router (ASBR) procedures for multihoming of Network V
irtualization Edge (NVE) devices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8365"/>
<seriesInfo name="DOI" value="10.17487/RFC8365"/>
</reference>
<reference anchor="RFC9522">
<front>
<title>Overview and Principles of Internet Traffic Engineering</titl
e>
<author fullname="A. Farrel" initials="A." role="editor" surname="Fa
rrel"/>
<date month="January" year="2024"/>
<abstract>
<t>This document describes the principles of traffic engineering (
TE) in the Internet. The document is intended to promote better understanding of
the issues surrounding traffic engineering in IP networks and the networks that
support IP networking and to provide a common basis for the development of traf
fic-engineering capabilities for the Internet. The principles, architectures, an
d methodologies for performance evaluation and performance optimization of opera
tional networks are also discussed.</t>
<t>This work was first published as RFC 3272 in May 2002. This doc
ument obsoletes RFC 3272 by making a complete update to bring the text in line w
ith best current practices for Internet traffic engineering and to include refer
ences to the latest relevant work in the IETF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9522"/>
<seriesInfo name="DOI" value="10.17487/RFC9522"/>
</reference>
<reference anchor="RFC4026">
<front>
<title>Provider Provisioned Virtual Private Network (VPN) Terminolog
y</title>
<author fullname="L. Andersson" initials="L." surname="Andersson"/>
<author fullname="T. Madsen" initials="T." surname="Madsen"/>
<date month="March" year="2005"/>
<abstract>
<t>The widespread interest in provider-provisioned Virtual Private
Network (VPN) solutions lead to memos proposing different and overlapping solut
ions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2
VPNs and Layer 3 VPNs) have discussed these proposals and documented specificat
ions. This has lead to the development of a partially new set of concepts used t
o describe the set of VPN services.</t>
<t>To a certain extent, more than one term covers the same concept
, and sometimes the same term covers more than one concept. This document seeks
to make the terminology in the area clearer and more intuitive. This memo provid
es information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4026"/>
<seriesInfo name="DOI" value="10.17487/RFC4026"/>
</reference>
<reference anchor="RFC4176">
<front>
<title>Framework for Layer 3 Virtual Private Networks (L3VPN) Operat
ions and Management</title>
<author fullname="Y. El Mghazli" initials="Y." role="editor" surname
="El Mghazli"/>
<author fullname="T. Nadeau" initials="T." surname="Nadeau"/>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<author fullname="K. Chan" initials="K." surname="Chan"/>
<author fullname="A. Gonguet" initials="A." surname="Gonguet"/>
<date month="October" year="2005"/>
<abstract>
<t>This document provides a framework for the operation and manage
ment of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to pro
duce a coherent description of the significant technical issues that are importa
nt in the design of L3VPN management solutions. The selection of specific approa
ches, and making choices among information models and protocols are outside the
scope of this document. This memo provides information for the Internet communit
y.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4176"/>
<seriesInfo name="DOI" value="10.17487/RFC4176"/>
</reference>
<reference anchor="RFC6136">
<front>
<title>Layer 2 Virtual Private Network (L2VPN) Operations, Administr
ation, and Maintenance (OAM) Requirements and Framework</title>
<author fullname="A. Sajassi" initials="A." role="editor" surname="S
ajassi"/>
<author fullname="D. Mohan" initials="D." role="editor" surname="Moh
an"/>
<date month="March" year="2011"/>
<abstract>
<t>This document provides framework and requirements for Layer 2 V
irtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM)
. The OAM framework is intended to provide OAM layering across L2VPN services, p
seudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is in
tended to identify OAM requirements for L2VPN services, i.e., Virtual Private LA
N Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (
IPLS). Furthermore, if L2VPN service OAM requirements impose specific requiremen
ts on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are a
lso identified. This document is not an Internet Standards Track specification;
it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6136"/>
<seriesInfo name="DOI" value="10.17487/RFC6136"/>
</reference>
<reference anchor="RFC7422">
<front>
<title>Deterministic Address Mapping to Reduce Logging in Carrier-Gr
ade NAT Deployments</title>
<author fullname="C. Donley" initials="C." surname="Donley"/>
<author fullname="C. Grundemann" initials="C." surname="Grundemann"/
>
<author fullname="V. Sarawat" initials="V." surname="Sarawat"/>
<author fullname="K. Sundaresan" initials="K." surname="Sundaresan"/
>
<author fullname="O. Vautrin" initials="O." surname="Vautrin"/>
<date month="December" year="2014"/>
<abstract>
<t>In some instances, Service Providers (SPs) have a legal logging
requirement to be able to map a subscriber's inside address with the address us
ed on the public Internet (e.g., for abuse response). Unfortunately, many loggin
g solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic tran
slations. CGN port assignments are often per connection, but they could optional
ly use port ranges. Research indicates that per-connection logging is not scalab
le in many residential broadband services. This document suggests a way to manag
e CGN translations in such a way as to significantly reduce the amount of loggin
g required while providing traceability for abuse response. IPv6 is, of course,
the preferred solution. While deployment is in progress, SPs are forced by busin
ess imperatives to maintain support for IPv4. This note addresses the IPv4 part
of the network when a CGN solution is in use.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7422"/>
<seriesInfo name="DOI" value="10.17487/RFC7422"/>
</reference>
<reference anchor="RFC7510">
<front>
<title>Encapsulating MPLS in UDP</title>
<author fullname="X. Xu" initials="X." surname="Xu"/>
<author fullname="N. Sheth" initials="N." surname="Sheth"/>
<author fullname="L. Yong" initials="L." surname="Yong"/>
<author fullname="R. Callon" initials="R." surname="Callon"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="April" year="2015"/>
<abstract>
<t>This document specifies an IP-based encapsulation for MPLS, cal
led MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation
is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost M
ultipath) or link aggregation. The MPLS- in-UDP encapsulation technology must on
ly be deployed within a single network (with a single network operator) or netwo
rks of an adjacent set of cooperating network operators where traffic is managed
to avoid congestion, rather than over the Internet where congestion control is
required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not
congestion controlled and to UDP zero checksum usage with IPv6.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7510"/>
<seriesInfo name="DOI" value="10.17487/RFC7510"/>
</reference>
<reference anchor="RFC4360">
<front>
<title>BGP Extended Communities Attribute</title>
<author fullname="S. Sangli" initials="S." surname="Sangli"/>
<author fullname="D. Tappan" initials="D." surname="Tappan"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes the "extended community" BGP-4 attribut
e. This attribute provides a mechanism for labeling information carried in BGP-4
. These labels can be used to control the distribution of this information, or f
or other applications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4360"/>
<seriesInfo name="DOI" value="10.17487/RFC4360"/>
</reference>
<reference anchor="RFC1997">
<front>
<title>BGP Communities Attribute</title>
<author fullname="R. Chandra" initials="R." surname="Chandra"/>
<author fullname="P. Traina" initials="P." surname="Traina"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<date month="August" year="1996"/>
<abstract>
<t>This document describes an extension to BGP which may be used t
o pass additional information to both neighboring and remote BGP peers. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1997"/>
<seriesInfo name="DOI" value="10.17487/RFC1997"/>
</reference>
<reference anchor="I-D.cbs-teas-5qi-to-dscp-mapping">
<front>
<title>5QI to DiffServ DSCP Mapping Example for Enforcement of 5G En
d-to-End Network Slice QoS</title>
<author fullname="Luis M. Contreras" initials="L. M." surname="Contr
eras">
<organization>Telefonica</organization>
</author>
<author fullname="Ivan Bykov" initials="I." surname="Bykov">
<organization>Ribbon Communications</organization>
</author>
<author fullname="Krzysztof Grzegorz Szarkowicz" initials="K. G." su
rname="Szarkowicz">
<organization>Juniper Networks</organization>
</author>
<date day="21" month="October" year="2024"/>
<abstract>
<t> 5G End-to-End Network Slice QoS is an essential aspect of ne
twork
slicing, as described in both IETF drafts and the 3GPP
specifications. Network slicing allows for the creation of multiple
logical networks on top of a shared physical infrastructure, tailored
to support specific use cases or services. The primary goal of QoS
in network slicing is to ensure that the specific performance
requirements of each slice are met, including latency, reliability,
and throughput.
</t> <!-- [I-D.cbs-teas-5qi-to-dscp-mapping]
</abstract> draft-cbs-teas-5qi-to-dscp-mapping-04
</front> IESG State: I-D Exists
<seriesInfo name="Internet-Draft" value="draft-cbs-teas-5qi-to-dscp-ma Long Way
pping-03"/> -->
</reference>
<reference anchor="RFC2475">
<front>
<title>An Architecture for Differentiated Services</title>
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<author fullname="M. Carlson" initials="M." surname="Carlson"/>
<author fullname="E. Davies" initials="E." surname="Davies"/>
<author fullname="Z. Wang" initials="Z." surname="Wang"/>
<author fullname="W. Weiss" initials="W." surname="Weiss"/>
<date month="December" year="1998"/>
<abstract>
<t>This document defines an architecture for implementing scalable
service differentiation in the Internet. This memo provides information for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2475"/>
<seriesInfo name="DOI" value="10.17487/RFC2475"/>
</reference>
<reference anchor="RFC2698">
<front>
<title>A Two Rate Three Color Marker</title>
<author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
<author fullname="R. Guerin" initials="R." surname="Guerin"/>
<date month="September" year="1999"/>
<abstract>
<t>This document defines a Two Rate Three Color Marker (trTCM), wh
ich can be used as a component in a Diffserv traffic conditioner. This memo prov
ides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2698"/>
<seriesInfo name="DOI" value="10.17487/RFC2698"/>
</reference>
<reference anchor="RFC4115">
<front>
<title>A Differentiated Service Two-Rate, Three-Color Marker with Ef
ficient Handling of in-Profile Traffic</title>
<author fullname="O. Aboul-Magd" initials="O." surname="Aboul-Magd"/
>
<author fullname="S. Rabie" initials="S." surname="Rabie"/>
<date month="July" year="2005"/>
<abstract>
<t>This document describes a two-rate, three-color marker that has
been in use for data services including Frame Relay services. This marker can b
e used for metering per-flow traffic in the emerging IP and L2 VPN services. The
marker defined here is different from previously defined markers in the handlin
g of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate s
haping requirements on customer edge (CE) devices. This memo provides informatio
n for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4115"/>
<seriesInfo name="DOI" value="10.17487/RFC4115"/>
</reference>
<reference anchor="RFC7806">
<front>
<title>On Queuing, Marking, and Dropping</title>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="R. Pan" initials="R." surname="Pan"/>
<date month="April" year="2016"/>
<abstract>
<t>This note discusses queuing and marking/dropping algorithms. Wh
ile these algorithms may be implemented in a coupled manner, this note argues th
at specifications, measurements, and comparisons should decouple the different a
lgorithms and their contributions to system behavior.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7806"/>
<seriesInfo name="DOI" value="10.17487/RFC7806"/>
</reference>
<reference anchor="RFC2474">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"/>
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="December" year="1998"/>
<abstract>
<t>This document defines the IP header field, called the DS (for d
ifferentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC8100">
<front>
<title>Diffserv-Interconnection Classes and Practice</title>
<author fullname="R. Geib" initials="R." role="editor" surname="Geib
"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="March" year="2017"/>
<abstract>
<t>This document defines a limited common set of Diffserv Per-Hop
Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connect
ions of two separately administered and operated networks, and it explains how t
his approach can simplify network configuration and operation. Many network prov
iders operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates fo
r traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for inte
rconnection with other networks. This document offers a simple interconnection a
pproach that may simplify operation of Diffserv for network interconnection amon
g providers that use MPLS and apply the Short Pipe Model. While motivated by the
requirements of MPLS network operators that use Short Pipe Model tunnels, this
document is applicable to other networks, both MPLS and non-MPLS.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8100"/>
<seriesInfo name="DOI" value="10.17487/RFC8100"/>
</reference>
<reference anchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author fullname="D. Awduche" initials="D." surname="Awduche"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<author fullname="D. Gan" initials="D." surname="Gan"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/
>
<author fullname="G. Swallow" initials="G." surname="Swallow"/>
<date month="December" year="2001"/>
<abstract>
<t>This document describes the use of RSVP (Resource Reservation P
rotocol), including all the necessary extensions, to establish label-switched pa
ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP
is completely identified by the label applied at the ingress node of the path,
these paths may be treated as tunnels. A key application of LSP tunnels is traff
ic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC9256">
<front>
<title>Segment Routing Policy Architecture</title>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
<author fullname="P. Mattes" initials="P." surname="Mattes"/>
<date month="July" year="2022"/>
<abstract>
<t>Segment Routing (SR) allows a node to steer a packet flow along
any path. Intermediate per-path states are eliminated thanks to source routing.
SR Policy is an ordered list of segments (i.e., instructions) that represent a
source-routed policy. Packet flows are steered into an SR Policy on a node where
it is instantiated called a headend node. The packets steered into an SR Policy
carry an ordered list of segments associated with that SR Policy.</t>
<t>This document updates RFC 8402 as it details the concepts of SR
Policy and steering into an SR Policy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
<reference anchor="RFC9350">
<front>
<title>IGP Flexible Algorithm</title>
<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
enak"/>
<author fullname="S. Hegde" initials="S." surname="Hegde"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/
>
<author fullname="A. Gulko" initials="A." surname="Gulko"/>
<date month="February" year="2023"/>
<abstract>
<t>IGP protocols historically compute the best paths over the netw
ork based on the IGP metric assigned to the links. Many network deployments use
RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a
path that is computed using different metrics or constraints than the shortest
IGP path. This document specifies a solution that allows IGPs themselves to comp
ute constraint-based paths over the network. This document also specifies a way
of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets alo
ng the constraint-based paths.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9350"/>
<seriesInfo name="DOI" value="10.17487/RFC9350"/>
</reference>
<reference anchor="RFC9182">
<front>
<title>A YANG Network Data Model for Layer 3 VPNs</title>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<author fullname="A. Aguado" initials="A." surname="Aguado"/>
<date month="February" year="2022"/>
<abstract>
<t>As a complement to the Layer 3 Virtual Private Network Service
Model (L3SM), which is used for communication between customers and service prov
iders, this document defines an L3VPN Network Model (L3NM) that can be used for
the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a se
rvice provider network. The model provides a network-centric view of L3VPN servi
ces.</t>
<t>The L3NM is meant to be used by a network controller to derive
the configuration information that will be sent to relevant network devices. The
model can also facilitate communication between a service orchestrator and a ne
twork controller/orchestrator.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9182"/>
<seriesInfo name="DOI" value="10.17487/RFC9182"/>
</reference>
<reference anchor="RFC9291">
<front>
<title>A YANG Network Data Model for Layer 2 VPNs</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="L. Munoz" initials="L." surname="Munoz"/>
<date month="September" year="2022"/>
<abstract>
<t>This document defines an L2VPN Network Model (L2NM) that can be
used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) serv
ices within a network (e.g., a service provider network). The L2NM complements t
he L2VPN Service Model (L2SM) by providing a network-centric view of the service
that is internal to a service provider. The L2NM is particularly meant to be us
ed by a network controller to derive the configuration information that will be
sent to relevant network devices.</t>
<t>Also, this document defines a YANG module to manage Ethernet se
gments and the initial versions of two IANA-maintained modules that include a se
t of identities of BGP Layer 2 encapsulation types and pseudowire types.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9291"/>
<seriesInfo name="DOI" value="10.17487/RFC9291"/>
</reference>
<reference anchor="RFC5440">
<front>
<title>Path Computation Element (PCE) Communication Protocol (PCEP)<
/title>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname=
"Vasseur"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname=
"Le Roux"/>
<date month="March" year="2009"/>
<abstract>
<t>This document specifies the Path Computation Element (PCE) Comm
unication Protocol (PCEP) for communications between a Path Computation Client (
PCC) and a PCE, or between two PCEs. Such interactions include path computation
requests and path computation replies as well as notifications of specific state
s related to the use of a PCE in the context of Multiprotocol Label Switching (M
PLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be fl
exible and extensible so as to easily allow for the addition of further messages
and objects, should further requirements be expressed in the future. [STANDARDS
-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5440"/>
<seriesInfo name="DOI" value="10.17487/RFC5440"/>
</reference>
<reference anchor="RFC9408">
<front>
<title>A YANG Network Data Model for Service Attachment Points (SAPs
)</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="S. Barguil" initials="S." surname="Barguil"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="V. Lopez" initials="V." surname="Lopez"/>
<date month="June" year="2023"/>
<abstract>
<t>This document defines a YANG data model for representing an abs
tract view of the provider network topology that contains the points from which
its services can be attached (e.g., basic connectivity, VPN, network slices). Al
so, the model can be used to retrieve the points where the services are actually
being delivered to customers (including peer networks).</t>
<t>This document augments the 'ietf-network' data model defined in
RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs ar
e the network reference points to which network services, such as Layer 3 Virtua
l Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be att
ached. One or multiple services can be bound to the same SAP. Both User-to-Netwo
rk Interface (UNI) and Network-to-Network Interface (NNI) are supported in the S
AP data model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9408"/>
<seriesInfo name="DOI" value="10.17487/RFC9408"/>
</reference>
<reference anchor="RFC8299">
<front>
<title>YANG Data Model for L3VPN Service Delivery</title>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/>
<author fullname="K. Ogaki" initials="K." surname="Ogaki"/>
<date month="January" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used for co
mmunication between customers and network operators and to deliver a Layer 3 pro
vider-provisioned VPN service. This document is limited to BGP PE-based VPNs as
described in RFCs 4026, 4110, and 4364. This model is intended to be instantiate
d at the management system to deliver the overall service. It is not a configura
tion model to be used directly on network elements. This model provides an abstr
acted view of the Layer 3 IP VPN service configuration components. It will be up
to the management system to take this model as input and use specific configura
tion models to configure the different network elements to deliver the service.
How the configuration of network elements is done is out of scope for this docum
ent.</t>
<t>This document obsoletes RFC 8049; it replaces the unimplementab
le module in that RFC with a new module with the same name that is not backward
compatible. The changes are a series of small fixes to the YANG module and some
clarifications to the text.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8299"/>
<seriesInfo name="DOI" value="10.17487/RFC8299"/>
</reference>
<reference anchor="RFC8466">
<front>
<title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery</title>
<author fullname="B. Wen" initials="B." surname="Wen"/>
<author fullname="G. Fioccola" initials="G." role="editor" surname="
Fioccola"/>
<author fullname="C. Xie" initials="C." surname="Xie"/>
<author fullname="L. Jalil" initials="L." surname="Jalil"/>
<date month="October" year="2018"/>
<abstract>
<t>This document defines a YANG data model that can be used to con
figure a Layer 2 provider-provisioned VPN service. It is up to a management syst
em to take this as an input and generate specific configuration models to config
ure the different network elements to deliver the service. How this configuratio
n of network elements is done is out of scope for this document.</t>
<t>The YANG data model defined in this document includes support f
or point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual P
rivate LAN Services (VPLSs) that use Pseudowires signaled using the Label Distri
bution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs
4761 and 6624.</t>
<t>The YANG data model defined in this document conforms to the Ne
twork Management Datastore Architecture defined in RFC 8342.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8466"/>
<seriesInfo name="DOI" value="10.17487/RFC8466"/>
</reference>
<reference anchor="RFC9330">
<front>
<title>Low Latency, Low Loss, and Scalable Throughput (L4S) Internet
Service: Architecture</title>
<author fullname="B. Briscoe" initials="B." role="editor" surname="B
riscoe"/>
<author fullname="K. De Schepper" initials="K." surname="De Schepper
"/>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="G. White" initials="G." surname="White"/>
<date month="January" year="2023"/>
<abstract>
<t>This document describes the L4S architecture, which enables Int
ernet applications to achieve low queuing latency, low congestion loss, and scal
able throughput control. L4S is based on the insight that the root cause of queu
ing delay is in the capacity-seeking congestion controllers of senders, not in t
he queue itself. With the L4S architecture, all Internet applications could (but
do not have to) transition away from congestion control algorithms that cause s
ubstantial queuing delay and instead adopt a new class of congestion controls th
at can seek capacity with very little queuing. These are aided by a modified for
m of Explicit Congestion Notification (ECN) from the network. With this new arch
itecture, applications can have both low latency and high throughput.</t>
<t>The architecture primarily concerns incremental deployment. It
defines mechanisms that allow the new class of L4S congestion controls to coexis
t with 'Classic' congestion controls in a shared network. The aim is for L4S lat
ency and throughput to be usually much better (and rarely worse) while typically
not impacting Classic performance.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9330"/>
<seriesInfo name="DOI" value="10.17487/RFC9330"/>
</reference>
<reference anchor="RFC6291">
<front>
<title>Guidelines for the Use of the "OAM" Acronym in the IETF</titl
e>
<author fullname="L. Andersson" initials="L." surname="Andersson"/>
<author fullname="H. van Helvoort" initials="H." surname="van Helvoo
rt"/>
<author fullname="R. Bonica" initials="R." surname="Bonica"/>
<author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
<author fullname="S. Mansfield" initials="S." surname="Mansfield"/>
<date month="June" year="2011"/>
<abstract>
<t>At first glance, the acronym "OAM" seems to be well-known and w
ell-understood. Looking at the acronym a bit more closely reveals a set of recur
ring problems that are revisited time and again.</t>
<t>This document provides a definition of the acronym "OAM" (Opera
tions, Administration, and Maintenance) for use in all future IETF documents tha
t refer to OAM. There are other definitions and acronyms that will be discussed
while exploring the definition of the constituent parts of the "OAM" term. This
memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="161"/>
<seriesInfo name="RFC" value="6291"/>
<seriesInfo name="DOI" value="10.17487/RFC6291"/>
</reference>
<reference anchor="RFC7276">
<front>
<title>An Overview of Operations, Administration, and Maintenance (O
AM) Tools</title>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
<author fullname="E. Bellagamba" initials="E." surname="Bellagamba"/
>
<author fullname="Y. Weingarten" initials="Y." surname="Weingarten"/
>
<date month="June" year="2014"/>
<abstract>
<t>Operations, Administration, and Maintenance (OAM) is a general
term that refers to a toolset for fault detection and isolation, and for perform
ance measurement. Over the years, various OAM tools have been defined for variou
s layers in the protocol stack.</t>
<t>This document summarizes some of the OAM tools defined in the I
ETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudo
wires, and Transparent Interconnection of Lots of Links (TRILL). This document f
ocuses on tools for detecting and isolating failures in networks and for perform
ance monitoring. Control and management aspects of OAM are outside the scope of
this document. Network repair functions such as Fast Reroute (FRR) and protectio
n switching, which are often triggered by OAM protocols, are also out of the sco
pe of this document.</t>
<t>The target audience of this document includes network equipment
vendors, network operators, and standards development organizations. This docum
ent can be used as an index to some of the main OAM tools defined in the IETF. A
t the end of the document, a list of the OAM toolsets and a list of the OAM func
tions are presented as a summary.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7276"/>
<seriesInfo name="DOI" value="10.17487/RFC7276"/>
</reference>
<reference anchor="RFC5286">
<front>
<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates
</title>
<author fullname="A. Atlas" initials="A." role="editor" surname="Atl
as"/>
<author fullname="A. Zinin" initials="A." role="editor" surname="Zin
in"/>
<date month="September" year="2008"/>
<abstract>
<t>This document describes the use of loop-free alternates to prov
ide local protection for unicast traffic in pure IP and MPLS/LDP networks in the
event of a single failure, whether link, node, or shared risk link group (SRLG)
. The goal of this technology is to reduce the packet loss that happens while ro
uters converge after a topology change due to a failure. Rapid failure repair is
achieved through use of precalculated backup next-hops that are loop-free and s
afe to use until the distributed network convergence process completes. This sim
ple approach does not require any support from other routers. The extent to whic
h this goal can be met by this specification is dependent on the topology of the
network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5286"/>
<seriesInfo name="DOI" value="10.17487/RFC5286"/>
</reference>
<reference anchor="RFC5714">
<front>
<title>IP Fast Reroute Framework</title>
<author fullname="M. Shand" initials="M." surname="Shand"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<date month="January" year="2010"/>
<abstract>
<t>This document provides a framework for the development of IP fa
st- reroute mechanisms that provide protection against link or router failure by
invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechani
sms are applicable to a network employing conventional IP routing and forwarding
. This document is not an Internet Standards Track specification; it is publishe
d for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5714"/>
<seriesInfo name="DOI" value="10.17487/RFC5714"/>
</reference>
<reference anchor="RFC8355">
<front>
<title>Resiliency Use Cases in Source Packet Routing in Networking (
SPRING) Networks</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="March" year="2018"/>
<abstract>
<t>This document identifies and describes the requirements for a s
et of use cases related to Segment Routing network resiliency on Source Packet R
outing in Networking (SPRING) networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8355"/>
<seriesInfo name="DOI" value="10.17487/RFC8355"/>
</reference>
<reference anchor="RFC9375">
<front>
<title>A YANG Data Model for Network and VPN Service Performance Mon
itoring</title>
<author fullname="B. Wu" initials="B." role="editor" surname="Wu"/>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="B. Wen" initials="B." surname="Wen"/>
<date month="April" year="2023"/>
<abstract>
<t>The data model for network topologies defined in RFC 8345 intro
duces vertical layering relationships between networks that can be augmented to
cover network and service topologies. This document defines a YANG module for pe
rformance monitoring (PM) of both underlay networks and overlay VPN services tha
t can be used to monitor and manage network performance on the topology of both
layers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9375"/>
<seriesInfo name="DOI" value="10.17487/RFC9375"/>
</reference>
<reference anchor="RFC7799">
<front>
<title>Active and Passive Metrics and Methods (with Hybrid Types In-
Between)</title>
<author fullname="A. Morton" initials="A." surname="Morton"/>
<date month="May" year="2016"/>
<abstract>
<t>This memo provides clear definitions for Active and Passive per
formance assessment. The construction of Metrics and Methods can be described as
either "Active" or "Passive". Some methods may use a subset of both Active and
Passive attributes, and we refer to these as "Hybrid Methods". This memo also de
scribes multiple dimensions to help evaluate new methods as they emerge.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7799"/>
<seriesInfo name="DOI" value="10.17487/RFC7799"/>
</reference>
<reference anchor="RFC8641">
<front>
<title>Subscription to YANG Notifications for Datastore Updates</tit
le>
<author fullname="A. Clemm" initials="A." surname="Clemm"/>
<author fullname="E. Voit" initials="E." surname="Voit"/>
<date month="September" year="2019"/>
<abstract>
<t>This document describes a mechanism that allows subscriber appl
ications to request a continuous and customized stream of updates from a YANG da
tastore. Providing such visibility into updates enables new capabilities based o
n the remote mirroring and monitoring of configuration and operational state.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8641"/>
<seriesInfo name="DOI" value="10.17487/RFC8641"/>
</reference>
<reference anchor="RFC4365">
<front>
<title>Applicability Statement for BGP/MPLS IP Virtual Private Netwo
rks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<date month="February" year="2006"/>
<abstract>
<t>This document provides an Applicability Statement for the Virtu
al Private Network (VPN) solution described in RFC 4364 and other documents list
ed in the References section. This memo provides information for the Internet co
mmunity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4365"/>
<seriesInfo name="DOI" value="10.17487/RFC4365"/>
</reference>
<reference anchor="RFC6624">
<front>
<title>Layer 2 Virtual Private Networks Using BGP for Auto-Discovery
and Signaling</title>
<author fullname="K. Kompella" initials="K." surname="Kompella"/>
<author fullname="B. Kothari" initials="B." surname="Kothari"/>
<author fullname="R. Cherukuri" initials="R." surname="Cherukuri"/>
<date month="May" year="2012"/>
<abstract>
<t>Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay
or ATM circuits have been around a long time; more recently, Ethernet VPNs, incl
uding Virtual Private LAN Service, have become popular. Traditional L2VPNs often
required a separate Service Provider infrastructure for each type and yet anoth
er for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome.
This document presents a new approach to the problem of offering L2VPN services
where the L2VPN customer's experience is virtually identical to that offered by
traditional L2VPNs, but such that a Service Provider can maintain a single netw
ork for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning meth
odology for all services. This document is not an Internet Standards Track speci
fication; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6624"/>
<seriesInfo name="DOI" value="10.17487/RFC6624"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data encod
ing for the configuration data as well as the protocol messages. The NETCONF pro
tocol operations are realized as remote procedure calls (RPCs). This document ob
soletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/>
<date month="January" year="2006"/>
<abstract>
<t>The Secure Shell Protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network. This document
describes the SSH authentication protocol framework and public key, password, a
nd host-based client authentication methods. Additional authentication methods a
re described in separate documents. The SSH authentication protocol runs on top
of the SSH transport layer protocol and provides a single authenticated tunnel f
or the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="I-D.ietf-teas-ns-controller-models">
<front>
<title>IETF Network Slice Controller and its Associated Data Models<
/title>
<author fullname="Luis M. Contreras" initials="L. M." surname="Contr
eras">
<organization>Telefonica</organization>
</author>
<author fullname="Reza Rokui" initials="R." surname="Rokui">
<organization>Ciena</organization>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Nvidia</organization>
</author>
<author fullname="Bo Wu" initials="B." surname="Wu">
<organization>Huawei</organization>
</author>
<author fullname="Xufeng Liu" initials="X." surname="Liu">
<organization>Alef Edge</organization>
</author>
<date day="3" month="March" year="2025"/>
<abstract>
<t> This document describes an approach for structuring the IETF
Network
Slice Controller as well as how to use different data models being
defined for IETF Network Slice Service provision (and how they are
related). It is not the purpose of this document to standardize or
constrain the implementation the IETF Network Slice Controller.
</t> <reference anchor="I-D.cbs-teas-5qi-to-dscp-mapping" target="https://datatracker
</abstract> .ietf.org/doc/html/draft-cbs-teas-5qi-to-dscp-mapping-04">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ns-controller <title>5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-E
-models-04"/> nd Network Slice QoS</title>
</reference> <author initials="L. M." surname="Contreras" fullname="Luis M. Contreras"
<reference anchor="RFC4111"> role="editor">
<front> <organization>Telefonica</organization>
<title>Security Framework for Provider-Provisioned Virtual Private N </author>
etworks (PPVPNs)</title> <author initials="I." surname="Bykov" fullname="Ivan Bykov" role="editor">
<author fullname="L. Fang" initials="L." role="editor" surname="Fang <organization>Ribbon Communications</organization>
"/> </author>
<date month="July" year="2005"/> <author initials="K. G." surname="Szarkowicz" fullname="Krzysztof Grzegorz
<abstract> Szarkowicz" role="editor">
<t>This document addresses security aspects pertaining to Provider <organization>Juniper Networks</organization>
-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security </author>
threats in the context of PPVPNs and defensive techniques to combat those threa <date month="July" day="5" year="2025" />
ts. It considers security issues deriving both from malicious behavior of anyone </front>
and from negligent or incorrect behavior of the providers. It also describes ho <seriesInfo name="Internet-Draft" value="draft-cbs-teas-5qi-to-dscp-mapping-0
w these security attacks should be detected and reported. It then discusses poss 4" />
ible user requirements for security of a PPVPN service. These user requirements
translate into corresponding provider requirements. In addition, the provider ma </reference>
y have additional requirements to make its network infrastructure secure to a le
vel that can meet the PPVPN customer's expectations. Finally, this document defi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
nes a template that may be used to describe and analyze the security characteris 475.xml"/>
tics of a specific PPVPN technology. This memo provides information for the Inte <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
rnet community.</t> 698.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 115.xml"/>
<seriesInfo name="RFC" value="4111"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="DOI" value="10.17487/RFC4111"/> 806.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<reference anchor="RFC4381"> 474.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Analysis of the Security of BGP/MPLS IP Virtual Private Netwo 100.xml"/>
rks (VPNs)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="M. Behringer" initials="M." surname="Behringer"/> 209.xml"/>
<date month="February" year="2006"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 256.xml"/>
<t>This document analyses the security of the BGP/MPLS IP virtual <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
private network (VPN) architecture that is described in RFC 4364, for the benefi 350.xml"/>
t of service providers and VPN users.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>The analysis shows that BGP/MPLS IP VPN networks can be as secu 182.xml"/>
re as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
Frame Relay. This memo provides information for the Internet community.</t> 291.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</front> 440.xml"/>
<seriesInfo name="RFC" value="4381"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="DOI" value="10.17487/RFC4381"/> 408.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<reference anchor="RFC9099"> 299.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Operational Security Considerations for IPv6 Networks</title> 466.xml"/>
<author fullname="É. Vyncke" surname="É. Vyncke"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="K. Chittimaneni" initials="K." surname="Chittimane 330.xml"/>
ni"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="M. Kaeo" initials="M." surname="Kaeo"/> 291.xml"/>
<author fullname="E. Rey" initials="E." surname="Rey"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="August" year="2021"/> 276.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<t>Knowledge and experience on how to operate IPv4 networks secure 286.xml"/>
ly is available, whether the operator is an Internet Service Provider (ISP) or a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
n enterprise internal network. However, IPv6 presents some new security challeng 714.xml"/>
es. RFC 4942 describes security issues in the protocol, but network managers als <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
o need a more practical, operations-minded document to enumerate advantages and/ 355.xml"/>
or disadvantages of certain choices.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document analyzes the operational security issues associat 375.xml"/>
ed with several types of networks and proposes technical and procedural mitigati <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
on techniques. This document is only applicable to managed networks, such as ent 799.xml"/>
erprise networks, service provider networks, or managed residential networks.</t <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
> 641.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 365.xml"/>
<seriesInfo name="RFC" value="9099"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<seriesInfo name="DOI" value="10.17487/RFC9099"/> 624.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<reference anchor="RFC5952"> 241.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>A Recommendation for IPv6 Address Text Representation</title> 040.xml"/>
<author fullname="S. Kawamura" initials="S." surname="Kawamura"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="M. Kawashima" initials="M." surname="Kawashima"/> 252.xml"/>
<date month="August" year="2010"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 446.xml"/>
<t>As IPv6 deployment increases, there will be a dramatic increase <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
in the need to use IPv6 addresses in text. While the IPv6 address architecture 000.xml"/>
in Section 2.2 of RFC 4291 describes a flexible model for text representation of
an IPv6 address, this flexibility has been causing problems for operators, syst <!-- [I-D.ietf-teas-ns-controller-models]
em engineers, and users. This document defines a canonical textual representatio draft-ietf-teas-ns-controller-models-05
n format. It does not define a format for internal storage, such as within an ap IESG State: I-D Exists as of 10/3/25
plication or database. It is expected that the canonical format will be followed -->
by humans and systems when representing IPv6 addresses as text, but all impleme
ntations must accept and be able to handle any legitimate RFC 4291 format. [STAN <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
DARDS-TRACK]</t> ietf-teas-ns-controller-models.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 111.xml"/>
<seriesInfo name="RFC" value="5952"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="DOI" value="10.17487/RFC5952"/> 381.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
099.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
952.xml"/>
</references> </references>
</references> </references>
<?line 2318?> <?line 2318?>
<section anchor="sec-v6-ex"> <section anchor="sec-v6-ex">
<name>An Example of Local IPv6 Addressing Plan for Network Functions</name <name>Example of Local IPv6 Addressing Plan for Network Functions</name>
>
<!-- [rfced] Will readers understand what "the above approach" is in this
sentence? Does this refer to the approach described in Section 4.2 or in
this document in general?
Original:
Different IPv6 address allocation schemes following the above
approach may be used, with one example allocation shown in Figure 31.
Perhaps:
Different IPv6 address allocation schemes following the
approach in this document may be used, with one example allocation shown
in Figure 31.
Or:
Different IPv6 address allocation schemes following the
approach in Section 4.2 may be used, with one example allocation shown
in Figure 31.
-->
<t>Different IPv6 address allocation <t>Different IPv6 address allocation
schemes following the above approach may be used, with one example allocation shown schemes following the above approach may be used, with one example allocation shown
in <xref target="_figure-11"/>.</t> in <xref target="_figure-11"/>.</t>
<figure anchor="_figure-11"> <figure anchor="_figure-11">
<name>An Example of S-NSSAI Embedded into an IPv6 Address</name> <name>Example of S-NSSAI Embedded into an IPv6 Address</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="208" width="336" viewBox="0 0 336 208" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="208" width="336" viewBox="0 0 336 208" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,80 L 8,112" fill="none" stroke="black"/>
<path d="M 328,80 L 328,112" fill="none" stroke="black"/> <path d="M 328,80 L 328,112" fill="none" stroke="black"/>
<path d="M 8,64 L 328,64" fill="none" stroke="black"/> <path d="M 8,64 L 328,64" fill="none" stroke="black"/>
<path d="M 8,80 L 328,80" fill="none" stroke="black"/> <path d="M 8,80 L 328,80" fill="none" stroke="black"/>
<path d="M 8,112 L 328,112" fill="none" stroke="black"/> <path d="M 8,112 L 328,112" fill="none" stroke="black"/>
<path d="M 8,128 L 152,128" fill="none" stroke="black"/> <path d="M 8,128 L 152,128" fill="none" stroke="black"/>
<path d="M 224,128 L 328,128" fill="none" stroke="black"/> <path d="M 224,128 L 328,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="336,128 324,122.4 324,133.6" fi ll="black" transform="rotate(0,328,128)"/> <polygon class="arrowhead" points="336,128 324,122.4 324,133.6" fi ll="black" transform="rotate(0,328,128)"/>
skipping to change at line 7678 skipping to change at line 7686
|xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd| |xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd|
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
<------------------128 bits-------------> <------------------128 bits------------->
tt - SST (8 bits) tt - SST (8 bits)
dddddd - SD (24 bits) dddddd - SD (24 bits)
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In reference to <xref target="_figure-11"/>, the most significant 96 bi ts of the IPv6 address <t>In reference to <xref target="_figure-11"/>, the most significant 96 bi ts of the IPv6 address
are unique to the NF, but do not carry any slice-specific information. The S- NSSAI information is embedded in the least are unique to the NF but do not carry any slice-specific information. The S-N SSAI information is embedded in the least
significant 32 bits. The 96-bit part of the address may be structured by the provider, for example, on the significant 32 bits. The 96-bit part of the address may be structured by the provider, for example, on the
geographical location or the DC identification. Refer to <xref section="2.1." geographical location or the DC identification. Refer to <xref section="2.1"
sectionFormat="of" target="RFC9099"/> for a discussion on the benefits of struc sectionFormat="of" target="RFC9099"/> for a discussion on the benefits of struct
turing an address plan around both services and geographic locations for more st uring an address plan around both services and geographic locations for more str
ructured security policies in a network.</t> uctured security policies in a network.</t>
<t><xref target="_figure-s-nssai-deployment"/> uses the example from <xref
target="_figure-11"/> to demonstrate a <!-- [rfced] We see some differences in the terms below in text in Appendix A
and Figure 32. Please review and let us know if updates are needed.
2001:db8:b:0::/96
2001:db8:b::/96
2001:db8:a:0::/96
2001:db8:a::/96
SST-01
SST=1
SST-03
SST=3
-->
<t><xref target="_figure-s-nssai-deployment"/> uses the example from <xref ta
rget="_figure-11"/> to demonstrate a
slicing deployment, where the entire S-NSSAI is embedded into IPv6 addresses used by slicing deployment, where the entire S-NSSAI is embedded into IPv6 addresses used by
NFs. Let us consider that "NF-A" has a set of tunnel termination points with unique per-slice IP addresses NFs. Let us consider that "NF-A" has a set of tunnel termination points with unique per-slice IP addresses
allocated from 2001:db8:a:0::/96, while "NF-B" uses a set of tunnel terminati on allocated from 2001:db8:a:0::/96, while "NF-B" uses a set of tunnel terminati on
points with per-slice IP addresses allocated from 2001:db8:b:0::/96. This exa mple shows points with per-slice IP addresses allocated from 2001:db8:b:0::/96. This exa mple shows
two slices: "customer A eMBB" (SST-01, SD-00001) and "customer B Massive Inte rnet of Things (MIoT)" (SST-03, SD-00003). two slices: "customer A eMBB" (SST-01, SD-00001) and "customer B MIoT" (SST-0 3, SD-00003).
For "customer A eMBB" slice, the tunnel IP addresses are auto-derived as the IP addresses {2001:db8:a::100:1, 2001:db8:b::100:1}, For "customer A eMBB" slice, the tunnel IP addresses are auto-derived as the IP addresses {2001:db8:a::100:1, 2001:db8:b::100:1},
where {:0100:0001} is used as the last two octets. "customer B MIoT" slice (S ST-3, where {:0100:0001} is used as the last two octets. "customer B MIoT" slice (S ST-3,
SD-00003) tunnel uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and simply SD-00003) tunnel uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and simply
adds {:0300:0003} as the last two octets. Leading zeros are not represented i n the resulting IPv6 addresses as per <xref target="RFC5952"/>.</t> adds {:0300:0003} as the last two octets. Leading zeros are not represented i n the resulting IPv6 addresses as per <xref target="RFC5952"/>.</t>
<figure anchor="_figure-s-nssai-deployment"> <figure anchor="_figure-s-nssai-deployment">
<name>Deployment Example with S-NSSAI Embedded into IPv6 Addresses</name > <name>Deployment Example with S-NSSAI Embedded into IPv6 Addresses</name >
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="352" width="552" viewBox="0 0 552 352" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="352" width="552" viewBox="0 0 552 352" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,128 L 8,224" fill="none" stroke="black"/> <path d="M 8,128 L 8,224" fill="none" stroke="black"/>
<path d="M 48,80 L 48,128" fill="none" stroke="black"/> <path d="M 48,80 L 48,128" fill="none" stroke="black"/>
skipping to change at line 7841 skipping to change at line 7866
| + - - - - - - - - + MIoT (SST=3) | | + - - - - - - - - + MIoT (SST=3) |
| | | |
2001:db8:a::300:3/128 2001:db8:b::300:3/128 2001:db8:a::300:3/128 2001:db8:b::300:3/128
o Tunnel (IPsec, GTP-U, etc.) termination point o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP * SDP
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="ext-abbr">
<name>Acronyms and Abbreviations</name>
<dl>
<dt>3GPP:</dt>
<dd>
<t>3rd Generation Partnership Project</t>
</dd>
<dt>5GC:</dt>
<dd>
<t>5G Core</t>
</dd>
<dt>5QI:</dt>
<dd>
<t>5G QoS Indicator</t>
</dd>
<dt>A2A:</dt>
<dd>
<t>Any-to-Any</t>
</dd>
<dt>AC:</dt>
<dd>
<t>Attachment Circuit</t>
</dd>
<dt>CE:</dt>
<dd>
<t>Customer Edge</t>
</dd>
<dt>CIR:</dt>
<dd>
<t>Committed Information Rate</t>
</dd>
<dt>CS:</dt>
<dd>
<t>Customer Site</t>
</dd>
<dt>CN:</dt>
<dd>
<t>Core Network</t>
</dd>
<dt>CoS:</dt>
<dd>
<t>Class of Service</t>
</dd>
<dt>CP:</dt>
<dd>
<t>Control Plane</t>
</dd>
<dt>CU:</dt>
<dd>
<t>Centralized Unit</t>
</dd>
<dt>CU-CP:</dt>
<dd>
<t>Centralized Unit Control Plane</t>
</dd>
<dt>CU-UP:</dt>
<dd>
<t>Centralized Unit User Plane</t>
</dd>
<dt>DC:</dt>
<dd>
<t>Data Center</t>
</dd>
<dt>DDoS:</dt>
<dd>
<t>Distributed Denial of Services</t>
</dd>
<dt>DSCP:</dt>
<dd>
<t>Differentiated Services Code Point</t>
</dd>
<dt>eCPRI:</dt>
<dd>
<t>enhanced Common Public Radio Interface</t>
</dd>
<dt>FIB:</dt>
<dd>
<t>Forwarding Information Base</t>
</dd>
<dt>GPRS:</dt>
<dd>
<t>Generic Packet Radio Service</t>
</dd>
<dt>gNB:</dt>
<dd>
<t>gNodeB</t>
</dd>
<dt>GTP:</dt>
<dd>
<t>GPRS Tunneling Protocol</t>
</dd>
<dt>GTP-U:</dt>
<dd>
<t>GPRS Tunneling Protocol User plane</t>
</dd>
<dt>IGP:</dt>
<dd>
<t>Interior Gateway Protocol</t>
</dd>
<dt>L2VPN:</dt>
<dd>
<t>Layer 2 Virtual Private Network</t>
</dd>
<dt>L3VPN:</dt>
<dd>
<t>Layer 3 Virtual Private Network</t>
</dd>
<dt>LSP:</dt>
<dd>
<t>Label Switched Path</t>
</dd>
<dt>MIoT:</dt>
<dd>
<t>Massive Internet of Things</t>
</dd>
<dt>MPLS:</dt>
<dd>
<t>Multiprotocol Label Switching</t>
</dd>
<dt>NF:</dt>
<dd>
<t>Network Function</t>
</dd>
<dt>NS:</dt>
<dd>
<t>Network Slice</t>
</dd>
<dt>NRP:</dt>
<dd>
<t>Network Resource Partition</t>
</dd>
<dt>NSC:</dt>
<dd>
<t>Network Slice Controller</t>
</dd>
<dt>PE:</dt>
<dd>
<t>Provider Edge</t>
</dd>
<dt>PIR:</dt>
<dd>
<t>Peak Information Rate</t>
</dd>
<dt>QoS:</dt>
<dd>
<t>Quality of Service</t>
</dd>
<dt>RAN:</dt>
<dd>
<t>Radio Access Network</t>
</dd>
<dt>RIB:</dt>
<dd>
<t>Routing Information Base</t>
</dd>
<dt>RSVP:</dt>
<dd>
<t>Resource Reservation Protocol</t>
</dd>
<dt>SD:</dt>
<dd>
<t>Slice Differentiator</t>
</dd>
<dt>SDP:</dt>
<dd>
<t>Service Demarcation Point</t>
</dd>
<dt>SLA:</dt>
<dd>
<t>Service Level Agreement</t>
</dd>
<dt>SLO:</dt>
<dd>
<t>Service Level Objective</t>
</dd>
<dt>S-NSSAI:</dt>
<dd>
<t>Single Network Slice Selection Assistance Information</t>
</dd>
<dt>SST:</dt>
<dd>
<t>Slice/Service Type</t>
</dd>
<dt>SR:</dt>
<dd>
<t>Segment Routing</t>
</dd>
<dt>SRv6:</dt>
<dd>
<t>Segment Routing version 6</t>
</dd>
<dt>TC:</dt>
<dd>
<t>Traffic Class</t>
</dd>
<dt>TE:</dt>
<dd>
<t>Traffic Engineering</t>
</dd>
<dt>TN:</dt>
<dd>
<t>Transport Network</t>
</dd>
<dt>UE:</dt>
<dd>
<t>User Equipment</t>
</dd>
<dt>UP:</dt>
<dd>
<t>User Plane</t>
</dd>
<dt>UPF:</dt>
<dd>
<t>User Plane Function</t>
</dd>
<dt>URLLC:</dt>
<dd>
<t>Ultra Reliable Low Latency Communication</t>
</dd>
<dt>VLAN:</dt>
<dd>
<t>Virtual Local Area Network</t>
</dd>
<dt>VPN:</dt>
<dd>
<t>Virtual Private Network</t>
</dd>
<dt>VRF:</dt>
<dd>
<t>Virtual Routing and Forwarding</t>
</dd>
<dt>VXLAN:</dt>
<dd>
<t>Virtual Extensible Local Area Network</t>
</dd>
</dl>
</section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would like to thank Adrian Farrel, Joel Halpern, Tarek <t>The authors would like to thank <contact fullname="Adrian Farrel"/>,
Saad, Greg Mirsky, Rüdiger Geib, Nicklous D. Morris, Daniele Ceccarel <contact fullname="Joel Halpern"/>, <contact fullname="Tarek Saad"/>,
li, Bo Wu, Xuesong Geng, and Deborah Brungard for <contact fullname="Greg Mirsky"/>, <contact fullname="Rüdiger Geib"/>,
their review of this document and for providing valuable comments.</t> <contact fullname="Nicklous D. Morris"/>, <contact fullname="Daniele
<t>Special thanks to Jie Dong and Adrian Farrel for the detailed and caref Ceccarelli"/>, <contact fullname="Bo Wu"/>, <contact fullname="Xuesong
ul reviews.</t> Geng"/>, and <contact fullname="Deborah Brungard"/> for their review of
<t>Thanks to Alvaro Retana and Mike McBride for the rtg-dir reviews, Yoshi this document and for providing valuable comments.</t>
fumi Nishida for <t>Special thanks to <contact fullname="Jie Dong"/> and <contact
the tsv-art review, Timothy Winters for the int-dir review, Lars Eggert for t fullname="Adrian Farrel"/> for the detailed and careful reviews.</t>
he genart review, <t>Thanks to <contact fullname="Alvaro Retana"/> and <contact
Joseph Salowey for the secdir review, and Tim Wicinski for the opsdir review. fullname="Mike McBride"/> for the rtg-dir reviews, <contact
</t> fullname="Yoshifumi Nishida"/> for the tsv-art review, <contact
<t>Thanks to Jim Guichard for the AD review.</t> fullname="Timothy Winters"/> for the int-dir review, <contact
<t>Thanks to Erik Kline, Ketan Talaulikar, and Deb Cooley for the IESG rev fullname="Lars Eggert"/> for the genart review, <contact
iew.</t> fullname="Joseph Salowey"/> for the secdir review, and <contact
fullname="Tim Wicinski"/> for the opsdir review.</t>
<t>Thanks to <contact fullname="Jim Guichard"/> for the AD review.</t>
<t>Thanks to <contact fullname="Erik Kline"/>, <contact fullname="Ketan
Talaulikar"/>, and <contact fullname="Deb Cooley"/> for the IESG
review.</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<contact fullname="John Drake"> <contact fullname="John Drake">
<organization/>
<address> <address>
<postal> <postal>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>je_drake@yahoo.com</email> <email>je_drake@yahoo.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Ivan Bykov"> <contact fullname="Ivan Bykov">
<organization>Ribbon Communications</organization> <organization>Ribbon Communications</organization>
<address> <address>
<postal> <postal>
<city>Tel Aviv</city> <city>Tel Aviv</city>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>ivan.bykov@rbbn.com</email> <email>ivan.bykov@rbbn.com</email>
</address> </address>
</contact> </contact>
skipping to change at line 8122 skipping to change at line 7923
<contact fullname="Reza Rokui"> <contact fullname="Reza Rokui">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<postal> <postal>
<city>Ottawa</city> <city>Ottawa</city>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>rrokui@ciena.com</email> <email>rrokui@ciena.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Luay Jalil"> <contact fullname="Luay Jalil">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<city>Dallas, TX</city> <city>Dallas</city><region>TX</region>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>luay.jalil@verizon.com</email> <email>luay.jalil@verizon.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Beny Dwi Setyawan"> <contact fullname="Beny Dwi Setyawan">
<organization>XL Axiata</organization> <organization>XL Axiata</organization>
<address> <address>
<postal> <postal>
<city>Jakarta</city> <city>Jakarta</city>
<country>Indonesia</country> <country>Indonesia</country>
</postal> </postal>
<email>benyds@xl.co.id</email> <email>benyds@xl.co.id</email>
</address> </address>
</contact> </contact>
skipping to change at line 8162 skipping to change at line 7967
<contact fullname="Mojdeh Amani"> <contact fullname="Mojdeh Amani">
<organization>British Telecom</organization> <organization>British Telecom</organization>
<address> <address>
<postal> <postal>
<city>London</city> <city>London</city>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>mojdeh.amani@bt.com</email> <email>mojdeh.amani@bt.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y9a3Mb17Eo+h2/Yg5ddQmEACiSkmxrO94BQVJmjkQhhGTn
VKUqNQSG5FgABsEMSNGG72+//VyvmcFDUk7dvWsjjojHrFevXr363Z1Op1Gk
xSR5Fe31ousknqS/xUWazaLsNrpKisds8TEaTtJRkke32SJ68Vq/zaMPeTq7
i/rLxSKZFdHl4PDt4M0wep+M7mfZJLtLk3yvEd/cLJIH6PxyOp8kU3gQ20Av
7xfxLJ9ni0J632uM4iK5yxZPr6J0dps1GvP0VSOKimz0KnpKcn47TubF/avo
GD7l0HaR3Ob6a/40dT+Osuk8HhXORxxcfm6Ms9EsnsKix4v4tuikSXHbKZI4
77y468zyTjrvwHTzztF3jXx5M03zHCBSPM2hweX5+4vGbDm9SRavGmOY8qvG
KJvlySxfQufFYpk0YLknjXiRxLDs62yJK95rIMjuFtlyDl++P+8N9xofkyf4
cgyL7ERvTn4eXNGbY3lDUImGyeIB/jYa8bK4z2BE+AlWE90uJxNewP9e/PaU
/1bAbr3uRsPf4sXH7DEd/YYPLTLc1mScFtkCP2eLu3gm2/sq+utyls6ThdlO
fGKUFgD+X9JkRp+y5azA/egt82KRxvhdMo3TyavoY25G+suv3FF3lhTl6V2n
o/t4MY6uMwBYkX/JtK6T2SzJvYldABIBdOy8FgseZ/2k/rqcpPEserMcJR93
mcGbbDbOfNB8mKVFMo7+N+zxOJs6M/l1gr1XzcOZyNvsHv6Oo9NsOYrHcUrw
KAEomN87WPQdLboKEDr+lLvu3mjXf8moXRdOQhkib5ZpHr3tRn1A80WyiPMy
WN4nk+Q2m6UjwgNAiCSB03UNIImjcRJNYmg8XeLvI3i+HeWHMwu5t/F4kY49
yA3ncTpzADaBKUzTu2UygSnKLKbLRTqZZH8pzNg0fWgEP7yCP/dFMc9fHR5O
pqYNPnHYaDToi/RmWVQem79m97PobBF/TOwkh8vZ7OkhniRVOzws4KznSBV7
02QhUNC9Tv45xq7+8hTfZ1k1hC8fAONOnz5mD2XQXqc3N0BxAX4MQPzWQTuA
fNR7SB+8aV3miziZOJNIYYDuDQ7wl8XNzax6FnCIfoth0z4u0/I0+nDuYzvs
u6KIH2Nv0H48A1zyzxt09ZcRtqzDrPgp+itcK5PygD8DIH/LHDQ5iyeTOG9H
7/++6xZMYJjurzjMXx641+rpnCazp+jsMQXKWjzB8mblWf39TdT7lMaFA4q/
xh/jReHD4hJpQZJ7ZPEGeh/nf/mEKNwFfC8N35umRXQGJzP9Na7Ag/jjskgc
eJzCiY0n2SIJR/ZGhd6K8V/ixWK0zKtX/Tb7dZzcw+gwWHnY00VapPk9nXA5
XrvTuykN0Y1xiL/cFDyPWbaYwiAPcEk28FI3n6DdaZZ97Lx4Te+dlzIjwCK8
zW7SSWLoMEAvGj7lRTLNo958vsji0f1e0FqvySh4dUrfeDgKsHuKBkmRLHJe
7w6N390tf0PSET/t2PB0ATcEoPxDmgTPEVsRHT87Pg6BEy/ukOoq2Xtx180Z
IrEApAtbC9QPnn0/7ByfdF88O6qD8PthJA8IWKN4MbqH7R0Vy0VC3F5xnyCv
Jj83X7wetkKIm7k+33IrYILAH70eDDasDXnDeNI9uZvPaVHjJP9YZPNpNl5O
kvxwOE9G6a0SS//jWVIATubdOJ9/+s/c/eVy/OeTo+fPDYC+6744ebYOQPwA
3F+z+I7Y1yiejWENo/sErkDq8z/w1hwBYwqEa5kn0SjOgUrhY4vkX8t0Qc3y
EuBq4FMHnlo4/1+D2/G3JwS3d53r3lX3l9ffd/8+GPZ6wzrwlZ7jlhF8E/39
Pl5OokE8+piAAPCYFgDPcdRz8I8hOMwmS5oo3hXIhEfPnnefPdsFljxob4Is
36j6pL1FxEfYnmyA7ePjYzfrAB9FkPUglBNsrl53j45O3IkoNOQXOE5DuH+B
ZIMY9HqZjpNJCreIWR6szl1cxcJoUa+Hb3vOl4Ic38FKnnAdR+4EKtZwl0/p
uj6cJY/5IoM3j/MOMkyAqYfL+SSLx/nhIU+58wBz6s7Ht7TAy/Pz8++eHXeP
eudVq9Sfore9PlyxI2DTiqeoCZ/yZNTaZmU4wJrZH3XTJElwGNoBGeEQvugc
xQlTvvP+4PqyDiuRyQI4D5Y3IGDBjTtOM7hQgfLfxiPkurGt/SLyzse2tw0t
ZO1AW+DZaL5Iu3hpHo6zxxlvCc3unw//PO4+++fxs6Pv//nsxT+Pno14dzqd
ThTfIFUagayhsnsOoyOuAX8fR7dJTLS9uI+L6DHOQdIuFkAYRnD4bp6I3J+A
sPY6mSVM2+CILgr4kN+n82iwyH6Fwxk1kTy1oC1c+nRDz+SG7oYKBLg7zPgg
UKeA6C5NpDsGWD7tBzgKkAmAjKaz0WQ5xmY4JYZdbzRK8tzoJJpwqlttgPIi
sd/18SukG1a7YH57f9XqNhrv7wEQIP0viZYDbRyBjIDExld2wDTtQoB0AgeO
c1Udhy44Asp1j3CFDoExndF0y2PDnX8LcoxoPhQicN5mAM70AY9IzoJ+lN38
St8lAMz391XzWCRLvF+Az3qKbpbphMB0M8lGMJ0R62ImT6TvyGbwBh4e41bp
AMAmPADVWdhNazDqTNPxGESfRuObCPGU0AKHDWFGa01otbMAx0RBpD23YRbI
jMs2euu9gWeSZGZAdLGcjZjQN68u8lYUjxYZ7PZ0OSnSuUWNKF8CpQbETcZ3
0OMkW45hGCB/cTRK8HDlvP843i+wTLhSEru1zV8AZxiuO6KAsld8cmQ/c3c3
Pby+Qbjjt8mnNCeNl2JO4WjHoib0hTMt0mmCx2VOtMKcnsKFeysqsiibw6Nw
YHB/cYsmPlBFWxS9SR5QZLwDEZ3n0xy+6QFQs9vbZAHoIPuUk+IN4JHxsuJ0
2vYHdaCD88xH2TzhmVWhOWAZ9Bp7l3jz99+BSHeo5R9/wOkcp3k8vQE5n2Q5
q04koCOkAGNyOEzl7vUB6fLFXTHjHhfxI89vDsg2RS5e5/gQL9IMT6bLrxlc
AoDyHicCCu0aH6euEZUAi2YFXAECA9nnMUA+W8DZ4y4VneEJ4ACrhyNiN4bm
sHI4jsVyTqIsSNmjewJ2PwUJLsXtguuypZMpZp1ZnsJ0lHoxrHPWcBbpDZwO
IkM4u9sFiBb0wDi5BcaCjv7vv/+v64v+9y+en/zxR/R4nwIa230Nz3A608Na
JJ8KnKEhdkhtAPkX2ZS0oB4ud+1NCehZj0axe5ay6D57jGBuEU4uVDfHCz2D
sAxcIUytRL1oi7AXIgy5bQnHjplKGKWMS4Ca2XKBz0KnQDuWeZFNodscMLcC
BNXIyAhzm951ktm4U2T4h/YpJNzQA6y7ep1RM+0m3bZ/kGk/AZtJYgaulch5
WrAgAfN7yCYPgo8hRAggc7i1U6IT+AiwYk38Ozjv5EgT5XD0+kQL3X2K8xze
5EwOCAYBYAC/AK+XLCFCS6TvHZoCcq8AbToxOr/8HkEGJ77ARQC0JrBRE0D/
2eipBZgIxCi6iXNgj/6WDQ9z3K4l3ZKIUyPsP1/eAkqlODfYR8T4yZPFdp/e
vTNXJ9K7dzkemP8XXlEc5w93wnGtOqXX+yveifIvq0aFAM+v6s2sfbxL/Q3P
BtH7JyChJ/ipW/v0ChtE5unnnS58t+7pVemL2qcf6L/gC3j6wF34gf35IIDJ
QfUvBw0at6/44k6J3g4UT92f/BbcRTREVDuKyl0oqMMuuMVxZLvw2/FkD4Jl
2c9+C+riQFaKD+EbOEL8WDinFf50wA/5XayuLqKDbrd7EPXPFVYHcAb9Lgby
2wE8vQq7CGfhjBrOQpZUmsVXgEVVFyHKhTvidfHFqIWnuPH7q+gbn9ayTPfn
vRrqHP0/dcc0GiI7ku/BRUHfdoBU383+vMcs5N4fa1heuUiD/sYJyMxPzGsx
WXPJ01kyBaZI5KksZYbsbIBcLjwJnHuMKlU0OeFxz6MToqLPkU5fAKO0wNMA
791rnHiBGhZVL9sxX2TuQuB98TTnOzoqFundHfGDwK4G8JGZI7MDjAzc7j8B
5Q4Z5OAp7H0+iUfCYDpzcwU6vKtTehaIARDrMTMUMekZq7pt0z2zpHuY2Mhu
9BbWKhIUXmjMZ+WGCUPxlEBIXEr1nJtJ9w5u3an0hH2rgBQjD4WiBO8PXF+w
+yBFtSNuQxzVf152zrq+2ZjH6RAP0oF+lZU3uwUrVLYd4DRLIkIqwhSYg9V0
m6lOEpKJol6eyx0Kkplo0eHr5rBzNRz2LlsEbxq3odyqoNvvvxs1MEwjOk1G
MaoopSFzSrOsiPD+RkayyFggMSeKmdc2zl352BHwMsmneZYnqh8Wtits3OAW
iF4KZ3gEmiKrWbDUxoAwPPYi1515Ez/BgTjWNydt4Krl/XPgWwbAqjC7auGh
++8xLcwhlvnGFFURIA4tmEWMeSP27uHpDshJe92I2W/8Aj53ZPXAQU9gL1Ba
BBYe8UZbRIA099k4t5thVj1fLhBcKGp/mE3Sj4k5rMpriVQB03vEuRbZCJAE
mM9klrNQzEAp4Z31VSB5pajUGKwhCISBZikldcLWSoTdRFkWwXlyNIPmUUs3
PPo5XRTLeAIMQ/qAkpIR3sk1ooUwADL4/OXL57AXAPtDgxcna9qeuG1PqK0u
BnZV+FPcOWI9oYs8QULA1Kt5DEcMpKnO3SImoUrFB3OeZfWGyTkf3+GyBuc5
7ErzpAUPxot8TQci31Rx9CyGNp9DJ/E8RsscnZoZbNTh1NglgCqiKmzMKnw6
2NIR7dwwEfXK77//QCIuMu6AKh3ahT/+aOsP/8ryDuCtfGPOcocOakcwmlvl
+BDOTZrq9Do6PaF8dNRCpFTM8ynftcIF9Y4pU7mr6wEJw7KE6NsuXYf2MhR8
EpJ7k04QRHCmjfIIeshLt0ij0ZvAgV3e3QdnwrntX7wunSlLM2+Xs3GMLVQh
gxI/7a6oUoEyqj0oUDrBcNhDigr3MROgG1hAdNrni2ucJfzEaBKnU/yZbQ1I
SGHQIlvAO5C+41maTz1FhivOo1R+HcNMFrBN0cfkKbrLALNF/POYgkyRBf7G
d0hPR6SxJdTy+YuE1FsTELngSU/HBXMYp5OnTvwAKBjDddIGtIa9fuowf4QL
RZVBivd6GSLxJM88kBBXRnMV/bBq9uheB34JgcICH+6qKiGZnXAxznkUtv0C
9TCsH0nxK6GPc6VVxD4YadrVZhlkwNMJwu1yMuZLBGcbXLV0Gs1xxDvzBm2q
y5moZMT8TUfkG2AReTZkR/IAY3gE4EimeZ1ap6x+Ie4Cl7OnEtYeK41myEtg
zyRGe7qhm2XhqJKyCYjrwmahImRpAdrMk4T3iy9JAALscQ7bBafxVaOhQ75q
vIp6wC3A5Y5HEm86IgZAUmbMcCDJJSKGAwWmVdEbOwx/ySmgjacEUO1pg6GA
ui7ZCrowPSJPMkGkAoTLI1FzeSoQ1OKECkvDUJZMC9P4I2yc7IEPT9pJB0rE
pxCo7GBM2Jl54dPDytILwwvcXQEdPY2ad1envDz4mVbYfPG63yLzjM8Idd3+
SZ8jWJmkSCNgcfP7p5wuPzohD3KZkoACu47tzd1UsY14dBeqxkK08UeH9Z1/
ipGm0HENmbRF4urh5nKB69h4l6LkhC0HMHCCvDB8NYDr9Qz5yD6JblHzDJaO
1C7kBPpoKoiaPw/6LeIk8fJHbvM+ywurXqxUqMHTwI3JRJRrgP02d1Wf73Dc
wcuS6tC7W9rliz/NmbtC7nLyxKRcKMrNEvX10dT3PViAWPAQw4e/4YEErIVB
jFTzt2zYwouJL3uY5F5Zw74XNWFJ4Q/JXotHpttgr7pN2CD2CBKZD5F4Mikk
1wmib0gCPgldR+6ZjhI5Bqeyu8pglsRVl4f5/XfopYMNhWpWmQ/QxHonmndo
U9INAAf0DZsPQMz/5htWBdTbNPhhNl8wZSaRxlq5SkwzYPKrr2y2pKuywt5i
oa/GW5J8Ub0gvJIoDpztQPL8+6t/LbMCFvQjaYqjfDnHjktGSTkVODOVrfpX
9BFdKrApolgvtzKyw2pGz7vPu+Xx23aiDmKzF5Ple8YgDI0Kx85VuTuvRJOg
egDUPyNTOctmHWeEsXTf9VaOMDUPEhhYSQEzeK+Lo4dq5iqYyZezx3b5tkCR
ikfZggkm4Uqpu5xREIVqb1I5ax14/VfeduXbbpazV5doQomhyShpa5/T+Ilg
Drw9cV3Abc2yCfY28j3CsC9n4iwRd6NL2oNbUteQ7TlP7vAB1JjgWpazFGX0
ttOeEHackjkSeqLrl4xIyJslfEug/IH6PuCm8AZMRwVZj64ujMBmGArDXtL6
2Tbs2ITpVlBgCWtJHanqjWxA4qjBFwUQJvjqF4Cc3LZovO2ADKn0Hw7lpZAr
M1+Bp9yqOe5AzBYv8crAU7FI5nR/FczwuNyNbyCP8Tgt5+RUsEgSy5mIJuJV
dNZv4xQZsO708aa2TgvVhI37R4630liZer4hRHytZbTKsBIqcyteqt9tiMqb
PwEpRWoCE/WIou30oKH67e1GWEWNknZ67QsbPGx+zL4eogZrzLebEj7bWF1d
uFr38oY4uu+Dq4uVHaGkJg8+6AjOesL1VXywj4dLf6j6gNPxOC0Zl5wa4FyI
nYKxkD40yntAlqrTePTxJpslNBM0ANGBW1GDAwsx+kvfHFi4RJ6hAhrs44P7
kfm7ilaDcxmY3q1e/6If4fFup+v9f13/1Pu+9/9VyQJiPq4qlxv0vunxYO5f
ufc1cy/jsY/cYoSSD7495kjNMMDlCYNfbTI/Q+fyeZaTmLvG9oJc2Wc5hihj
V8z+KPu/3RNnYO+caRLPHH8HvuRZtoR2E7ZkWz04fdcVGU86GSUerTcSo6NP
QKMEGr3ppiIt67Jo4DPWz0v85Gq9XDqyAmDdqnnERtCkmDlNiIXJgzmpBivQ
PyWf7mMQwFhL8g3sQsW0DJDNGI1GxWM1rKnPCurtKIolnzFlM5pqY1XPfDhX
vSCvYrRIYmI02BEPewLREQW+NM8mor61zh6kYEAfKvIpKbI5eq+Q0EXyIIrA
rKpXETGlPea4RGYFjErvEJADnRPM7yRX4oX79uodC8OzGN314hxm2yIxUsRb
8oQQNTMzk7KOaA+v4ASVfHvs74N758wf/fIVzd7DzX+N1z+wecZzUlVkS9jX
xeRJTCSO1wb0qgz6SQV7LttW8swC2OT+BsXh5jCSG7ZYvaPNz6geJuVsKjth
friPkTtKFsjhjGARjjyiHlyO5WGeLKgLBLXPdxv4Cv5uIhXOSWHZDjUz0R7w
cNTfniMQxzJEWufjKbYuESQDPzgWJKwG6Ha5IJVLMolvsgVHNc3INFo/5TRv
BLJ2nZaBWHL2issc6jZ2dIyVBBr3JByVJHzHfBSK9u9dWlbvKiU0AQDJ5zJp
N+6WsOuwgITODZzaDMOQfquCrT0AuOee3g1kBlerRF5g3nl51WA1CqDVJJ19
NDYUGjV5ALotIbqeafUUDjjI6peiWgOx5DFejKufuoCnEBK1CzdHQpF5nKBr
Jk8YcF8M0HbaKr9Zr0Q9st/hg//pWj48ickVRY2xSO8oGInJMXpcc9cYsLIk
84U4MptNAUkNkGW6nJJfAj3NEEMPgxSEWFgR6tfk4PEQ0JNIVHCppPwunE6X
TDs5a1PvUtwAfQQF0aVYlRHIaLd4vMcbOcPTkpsfAYHgpAZrx8O3GLPmLIf9
yW+fSMCbgIh1B8eGHZHvbMgFbqwhUrnjdKCie1thBgTBbs6I1P43vnkNZ3UD
jC2FtaCqbJqO8b3odSw4tutKWlNP2q2ogawNUG9CXBbJb8ndk5WGWbcgy+OD
iiI8OTQoD0T82Ey1FMbeEykBzB0ptOHYm9QJW5WseoKCo2INq82fry/yVqPO
vvq3bGj0X3ilNs6dHWu+P4el/3KfsJJ6ItrpfHkjVmv2uXXWgotMZmiAGnPY
gwOR0X3G2tvK6+E6UcbujKwZck845g24AkkrAVdHTLKw0U2waUjb8+M1ek0y
emSEh3ebxHNH4WLcmwGgxnbwABRQzc6VHo/WwS54OR555Ze2ooAvT0PgvGp/
KP8qkznjW7L8qv3B/tgoiylW/KlTBlT9esDikQsYFbscqFi5XAWlciuVs4zL
otNRxWvl/zVui57AJrKv6eigtJYDpyPvV+5IxULxDFyp96LnOej/GP7KHa2u
LlZdeK0cD0YezvFitC6M5lfPlbF6RlF5TP/H6hl9NRgFr213rdk/bzk/fD2E
rBz4s17c1Q+lwUskJvj9R1+qF/qmsn2JMBK/YM4CYTJpIYPTs9bFsmR5L9S8
4hDzHLjiGXOePt0NjEO+iZVuB2MEQ1nAn2uzP2wJcR/lMJl3M5QGVRS/QEHK
tcU+CRmO4vGY7ly4wOCSTCYaX8NKYjEqgsQJF6KJRco5vBVEQFXR+8ZPmCCa
dXEUYAXEIIkOF3Ds2p4lxNFf02/IHVgHUuPucjmAXua5ekL0z1nxn8OIKjOI
K0N1SNaFOKWh6oJ99ij4J4bmrtmYdOQg4yToxFllOVXxwLsl1NJ2VQMNGz1g
3NLEBjTBi4+CaJbwuHh2iGed7kA5nEx4FPVcuPRDGJpXFz9fkj1uVqDvjiX7
NgS02b/CRy7imwUwihwJjnsLM/FsBr3BZd5Sc4jraoQQNHf/PWmDmGOxy0KW
xfBfyTjEWXQnY+IjOIvGyB6SZQ7rlNUGEriyWt4uE9/tQ1z0RiP0IdTdLlnB
5aH5zPhbVXZPzhSwSWg1gLmoU1/gp0dRIsipzrIphlBR4EhFKBRGQplAqHhE
Q7viXv88V6sdWV4s2RB84IPYljPI5/EWTtQj8JE5y3bkxqKuFRyLg2YZYYWt
PC8CvvK+qAZfSHASJsWA7fmAzghpzllnzNdnH9jj4ANQh2hA7q6KnVHzw+Ci
hVyb7qX1znYMZa4XSpucdKBfPIQ09RvEpI4+btx3dAPJ68P+zsPYI8kj3GTS
yiCG6pFsN2ruQt1Xu/ywQRiVKO/jB+vlgGotY79KWK2WzW7Ru924aAlvW54w
qm5phsBpkB/PuXVx0IlyONIsQ0kI2HHkahQvUcKI1dUPDQ9IadVkbEOdoAXH
jNkApPt4Pk9muVHmTZ5cRxEEZZEnk1s+DgYA6rojnTqhgdhEATs4L7kM3VHY
NaJULnpkVdjwqYXWZntTJ0KXvLxcxOuf7/2HGkd5q+rOqomvu3kyG0L2aRN3
S5uVG5WTbrkaf9/zqgwFEhcqmUmXvL+sUWDsTZIQvjJUznMlymYSTBtzmjQj
qxsZKQ47ZkMD/ohw48MfNYUYybEX2qBfn7Q0mM/2hXQWSU5vlrG6bt1KAkbl
xbPQThqwfQdV3Fv4DLGqjshRyaHil254lfC3xOhE6xq5Mo5a39bOMOiJhIT1
j9Q1ktCmgFd3oXBQbiRWK3r6z6VXaSzbyFtZr+8u0Q/IMo2u31/TSMNfth/p
s9b0GdCDrpzTvuU+8QtQtXqYqkafhbCeFOEdJZUlHCNhQLTqhYVfSA1IGSfy
QjLs4OUvNAK5lsF5LnQC+F+5/pFFNbEBb3pXKBekytjl5CgIEMH7gK5Sp7dK
Hoi7Z1rgBfIrU0DW8M48Q/9ajr9FP3ucULGErid5BzmBIfvHGLWZPPPwMmoO
rx9eapjCd99/9xI9e4XE3lOIyhJuvEfgFmfoVIZxFjpHIYp5cK8KIPy4Izfc
RqeOkwEmihKRACN0/V7YI/7+jF28l2lOitjm9VkOfAtGhaEfeNvchzneoZjQ
o5p7Mbcf3Itpbgk4wQ0hA8t344L8CHNSf2IIMPAJZKrR6HsT0LzWjxO3mW90
jx0RWe0VczfIT6+n9nBxq/GhQ1tBiIh/lxQkdhsopfkmt/GBVb5yJizj6NkN
R7XYL0bs7AjiQEk1xcLAfEbCgMOAkfBUWn+RefdqyTt4Qyh4qT93Ay8H7CLF
MinAL5wySzADI8GQO+XgXPWzDxwuZZDGmb46eZXkX0WIChE2Vk4rjmQMlVPl
CM/Iwmu4nF4/96WMTawZ9OpwZ9txZYN/G1dWFtZYjjHfV/l4iRQ3qGfexHHX
nII4OAfKv+29tby6kKG9wDjj7Ceqvcn12mHllHLTSUI10nkuiSrwXBHvH1AU
011zREa4tOWzXhpjZmfmCkyx58r0GsSgR7wDclHmW42Srr6Zpi22lRvezvGG
d4UVukxIkEU8xQVBM7Nx1kLt0k4ShTkWLWcXT6FoFRqV/0oM5Tr2okJHeuA3
KnNMnjLXsFleoxre8O3sbmx8nlblRq6CW/lDE7gvTOJ2I+lP1SN91prqoOcx
gSH0qhrpl4Nz5+PnoVH5ETyCPrkrGWz+f4ihlZ5v1TOzMKaOgKkTlaA3Xu1u
rswX+oCPN2f9CrxZGddG9XA8cHD0IHr9SwWGlv0ct8DQSm/HTWuqwkIXemsx
FGWR7TB0S7T2PiLuOUT+s9CaqL6P06KA8sWcF88C2SYPhZvBOuEGdfNoryD/
+UjtFhXBQzYMUNgbnI8wnsR30k0pIbXkd+BMQXgGYczqdK3MnQETxLp75tOr
eBXVNvNdRxwnTEpVyYmokon/UtWxKFNEUAj4OXgOpbUKzqzEjJmQyBHnXa3Q
xwhwmiF/jRNz2eu5ThT1gdkkxUSatJLDXv/QZ/IcPtSLoCxKJg7XTu8lFFNZ
zjI5yAxhSmgMDWEfqkmFxLSWj8vVSQY16H2Pxc/F0iAPSuyrWcDISaUELUnu
4sBuka7YO7Ii90A2z+PHO05BEBtM6owYkwyISw1mxWPl860wYZgnfcjCrGir
Wr+9mwTQf7HXFmbRxFbkoQ+ky2FX+ExxPxT0MJksVTFOwNkDirmH7CCnYiFM
qtASKlI5qr+eTttIsU8d45DjmTFQ/MBzrP40b8htyU1diC40b3pXmBWux7Es
HiBM4GZqrVa8JvI7BQC+A1ZzAqzpz39HNcj5z5eVHaEgJ2CDZ7ULWMuZ40FD
yheb5YbXSJx1HY+u/sae6OvFoN9IYhIyNGpqPFZNEBRNYJgmysDsl3UZ+HY5
PBQTFqMpAH1aLx0fso9JMmersmx8njLCUEYMpFMwL7LvEr3t3GdToj2auE5Q
kZTgAJx2iJIMXOuM7bQwii4NHeYZdGGGgdRgEuwpfJJPbA1jaRT9r4rUKEk8
ebdaVp5JwNBcg2zFysYHEQHP9J6o9jTjXLIzAgdZNMh53/cLQtR7SJNHuVuI
FvIlhGa1c45/Osdkz+RL6Dd2U0J7vufsBiBXg9yZNmQJr6O7SXYDR8KmRNRg
qJJBmsK6nUAsdmpsxt2P3bhb8oRuqbPkb1k2xWPjhgtSJJwOeJ9M5uRap2Q+
tHaYhJq1ORBtAsonPtyxXGhmQ0xCSl1eYE5xEiPqTWpnWHOfOU5n3iFTcdjY
OiQ/1fPutxW+5Ox2YH3iKEkC47LciG0GvYMDvs+5xQVYWxM3YviuVRV77mcN
CHcsdzZX8k5IXgZr3oWeCZxiuCdCZEODPe/q92Ugayf+qPk8hp0SH33xcLwC
cpBHVAgpM4kcnBSpTCcwIo44zStm8GasCUvswlON/Tb+3U6Oek7Yr4yB+Ftw
0hGefp1PBp6l+SSl0JAsgsUgZ2piAmd0X2hOSoMtJa9HsyY3L8SrRqOkwHxX
QZIpEUJtoou2f7MsEkoqTZegjzp9410RNa+GfWLy1InHSzOR1B6+Gu1a6Zij
2/Nj7qeyKKfzxJSUXSfpA8mqdQDAPXoX7pHrcSRbFmRREHBQ1GhM7uYJI4nn
bCIMne/Q0o7OxeWhAo9gZcaPBvYkcKKRHoBFuXwr3gzqQezNyDo+E/EakaGX
nH2sA4LlGTAgVlf33kS4bEhz5KfM9acyTe/uC3aX8MPFEU4x+3rcZ1Q7piBB
xwSrVdRC8w5wD40K4/RT1Ou+rMjUV3LJrXp1jRTarX+ovv0qUiJW58a4oQMQ
+UmTgFqGte6IXujg7sNwSOmuHXQ9Ob27cwcrCYERShaVLa9VHTijHgTH8aDT
KmmHvAlyD56+sGmpemvTFFYVPbAOyLz210OhsofSa13cs9dDt2apa0Hg9rDC
k7jeY7xifJm86aOkUTyo/dRRK7w/i5VPgdHWrzk9h/2qn8s9+KvwN7Lm59VX
XQVhQkUq48rv8Nv9Soyowoy1PtD/hh6qELAaKR/cHg68ta7X2Ya/rUTLHCrz
7TsvNGJVemolSsmHcgeqKDVqZlfjf6ATosEdx3jzUK+vatmg65V68V9dwL8/
cCfso49JhtdmGY5cH/0D8iNdyfdVc3CGLM3BW0VU1s2GYPBhfxA8pR1UavvL
aOT+ZprIDCo0/+s7ME1CA8huuNTZ7L1v2MvaV00HjOAe44HYu3X77V8NO1zw
qk+O3ll5SnAV6lQTvlm0J674/dWGEIGaEg6OnTaQKUHWo8oIeW5Eo/08EA6G
yxtg5l1O17rkXg2Hby9alsFz0v6KtPuCebxdUwDXhSSzN1BeCr/FZL+uAsfE
LCNvy8CpUYAHOnfUpqbTdEJxxv3zDnttYAZqX8rSINMX3WM/wab6E3B66iOa
6TFl/7IZ7VFGeF4KdatQAeCmeGmF/L0MNTx/bIhUkGCEcWJ8Pll0pZw57LEt
7lZYv9dLuzeUtHvnnP/OKM2xWyc1kAl+8L3mM6cFpxNSvxTNKqgDa4KlG1Wr
gXjN4hsmM8rFecr3sFbVqqvJN2MMZIwKNYQzLG7DggJsbT7SasFbgycucl9n
2DL+WuukVpNjiNVg3bKcj0C+9nXzlfuJ+obBeUXlo4qlGYGW/YVmyL25kdIv
uydhlliQBktWLxW2KxQizngixdqyGixh86C6ft/xzvqkSQw+HEpFoM5tLLVW
1BVxJ0BvGIgxcCBWJk95a21uFLxDqvVZoglAGm4hD6LOjm7Q8cqLOVeV61Do
ZiVHQ0WncXmWt9GaEI/HsO95kh/mRHTh29PXA+BmlkU2y6ZI2rW8ZG/Yiq6o
sjbQ3GLURQdDpBrlvNayP43QT7za2OLWYszrrQbrQE/6cdruLs18atOTGqBp
BLSjPLV7k4rzJmbhxTPMffAxR/9Pisl3s2tLj2g8gFtRN0Q9Q19+z4Rxjcde
Giw1daO5IzzlYyzM/X96V6890x9ljBtc5kpivPWRsry6BgJSuUVCphFKY042
NskMTFbcV/amfs7xe7FUf/F8zNRfFy4qODKUs8HZ+gaBQeLy1d3NKpaaJjQd
kRBwkOsADJDw3qafKAgPTYUNUhzFZItSHHCVzblkgLOB++asKj9ABLmytsBb
Sr1GjESrzCfQO59TmN2knacY8/VEcsTLhKqDptaOSfTZ68fxsLWTUbakiSop
VSpeJbG/G4VFQaJ6MdCRrOmrhse6i4Bd3TT8ipqGknUUcS5oxNfDs7f4XLOk
ZC5VMYlIggpfP64Cw1WLRy1rXSpe+2Fv+2WmvFYPU/rhS5qGQsuqzvMlZPcP
SmHRD3WeNqF87sZ485vuETU9+v64+6wL/z884ej47jO/9IzGmZMM2z3on6/L
qHdg0qPVjGrgQb7+R8+eGSBVjBoFqRHWeBW56gA/5j/a1NTN7leTZ638qnjs
C0S8sKm78Xg1uchSEumeqzzXd++Syjw/116WHrn3Bs7tsUbSA8lIi7qUzWiV
FdzkNxaKpCzBH1zX2WQ6MfbuTBKfsYlm3Tia+eQVdfUnEHbg26tXjZ66VZXy
YokAgt2KVVxHtWlUmtyNpOvRvChtNwoRzY3JDIXdauH2BV74xjtFmQ+bRcWx
Qvq8GV6AS4w9VVbNmdctp1IxKzuf3ePExppl/XSRxeMbKj+RvD09bfn5tjTW
OZ1SzWmu0QaCTuKwIApthJLkWMtNhF86BT4koayzbwlA+jjASTJkGUPPDRpm
mSkHGj2VVDZ+aipEhdt0kRc0PbrxaBOpc1MH/a3uTxkDDA8jeVdF8FOAdbEy
qrilOHGwNWU3qepmy6bbsX4YDH2ZzqMmAcJHaHBHtJHYi3BTgygT5ImkNzcF
HhVj4jxAnB4IZBgJc9EkdqHLU6qJWgzevUS8Y2+fuD6G2Rz5DxPoCUjBJMX8
O9Gb7BEYOvY1w4LIy5kWhWl+uH7zpt/StGoKDSt/2tXbWq9t/JMbNcLd1Wk5
DtuZY7P/ofMBU8RzdiMgRVqhT4oQ0uH4NcVsUgpgFj4rTxGtb3AhXdAOwKGQ
FVAEvzt50RwsAOyUL4IW4GHklWKkjOjQH3tusukNZatCC6m7x+x0KZ4o0/ST
JhNLxkHGKWBys5HkWe9qQUNVNSjNaYcZlRwiIQTOJIuk+kaStgxLO9Ufp6bl
lH1ommVS3KzmJXN7mnk9tdyJ2wTW5Pkxl/pfAGLyxhrFEylGgnkX205IvdAY
c+A4XotA+Db68cfoijnk6uiKnV9lfsq8TKkzwp/aV6Bc32pCB6UeVF1/dVI2
PFW1hzHhUW1F/BkdI2M/0JeqhuFM/NNZyIHpCc6KOIo7JoNt5xBF3hzcRdVD
rO4hDw7H28Ph2M6B0g0jJPplSLjA6A9KG3YQ9d5+LUh4TaqtfcHLfyhgJD8D
llF9D7VJrZ2H/Nbb4XQjYEpfKFN6RE5h4pVHh7upG9FShnIN17nOLyMwClU8
AYuiqEZJYF35hO3loOaJFZySf9JduFrbx8GaPty/VU84hs+atZi+SmTvIGhd
sTtlbcA683DwNYf7JJOJscd5Sy4PV2E+r5zBGtTWn6/1bnYphB1mqz40gbn0
wbSSN9Q1lK7p48Afde1EDJnpvXkjX5lRXrzuE/WpiB7bbjG7TGQtROxXFiJ0
Q/wbIFLx0lHwZNGwq0q8/gyIVD23hoRVjLHuANdOZYvoO+mjjgKXh9hI8sqr
CcnwSyXDVwEZPtqNDMPQV47UCLz0iMIgKnxslS0GERmYUXL8zKkS3QR7uYWG
2YISSLMW2OnsBiOMMWkCxS+01Z72AN1klOXSTU8d/FzycMXMbsB8I9WKTW5q
7MQJNuDkwpPkjlZis8oCk6mqjrAKKFnIUEYWmU94ZL+kq2agvrKBOSj3pvPO
fXaL1l4UYilWAX3GjXe44ZNz9oSdU2JZh80vMlvK1YlOJlAGhXZNPAcJ51UZ
Tp14jjzZ3oW5KkSDc7VGFyjXW85ZigEMbdycpxBytAAUiONKCSUNTjobZYu5
5OEmT9RNShQXV7oNX6eTSqY9J+eDyQNBIjfnJJp4GYzI6brT/6APks84TYWo
J1vyQklXXJwdYbc/4O23Nj1bGyemZH7GaVvFQte0kUfnR+3o4qgzon+XbeCA
2W0dJAIbjw+geUierIiLPu0qUIK4Gy/GIvNhUnvn8O7RrmhudU1LvaTs4ZJj
XS12nH+LDoUJbUF/Cs7V7wRLCrq+STAs0NenqVWpUp327R9/kFbA6D40DF83
raa+z62ioefenIVpPshj+KIj5TzhHeyhzVlWZHeczZh34zELVHKmqqyHdTlS
1aH2iW8/DI5aXUDmTwVh2JSCoix586eD6RSh47E/8zybiM2uMmIoJiGuSQs4
bgUTd81jzuEwwn2T53jcMpk6nBNlQps8eGok2XI+jiU0NJWCbhocZtfwylNU
KHRaniONTQTZpP3gmt6scwDK8qNTidgqE1HbRRBlnC/rL6zaIp5mbmIOTasO
D2CdZ8ZXcjnHSsr/IfXKuNqWFHLFvcLUdN3ICbITW6yAWbS84SxuNR+71UAR
8OZZTpExrDSxDhFH7Nfz++9Xr7tHR+jXI+fNSfOCLRytVnM4fN9hh59ZJuTy
zFFoYljO8KzV0mqodKCpeAPAhgOwJk/diP1hXrzG3rljo4SxSGAKLCAaY8JF
exZdUQ1rRZ95mO3jUKNsA9v1tUZ1E95DdTzbmh62e1X0sIk/q+lhW5WDKBvc
x6WHFR0dR+0BNMhIIubYmQke0OOrrzsHd2EbIPdvhYOrCPsQggEJsg+HD18P
DqXHN6h/ygbejaAqQa6uRb2cUW6yE9rC6cVq6/4Bd7Ium5vC9QPxGKH/Of9B
D/9Nzv/wp971+Rn3YF9N/trJyi4/O4//DwX5r0RBPmOML1/X18UQcUXZuDuu
IcHHkGOzbxUYcmwxhBHkuAJDvmQOXw4H5/WZVOvzX+t6GLL4sIF8Vznq7PYq
6cq+VV0Z3x/IUIe6C+fSWxcTEVqI5xmWmbJ2WpN+nd2iWfOBfDpri0y0LAnc
pZA8eFDD7En24ihfdAAoOCemeHSWzMOLxGQhuofVTThhMzqC8nRNNT1VClC9
4LzQ6jVctYE8K2hFlAgRizQWLEKRjd5zmw3Ug0Z5xU64WL0Kq4mFT4JcFT+x
uGMCgtMZl7kFiIEsvYij0dNowiqxPEk+OnZmePMQU5og6Es0Uya/RW0R8Wtn
fHYOlVQY0LIDk+uQuGe8l7z5hrJpVZF0R8OBXRglxz0ssDNBr5TOv7Jcc8na
KhkVpcvJKK7OT9GbY0zSyE7Hz1++fM55biiT/4nzywn9ojtsyz5V13t6pbb8
9/cm16W7VgSjAeEtI6TurLg4i4+w9CMZJZ/YvUtKZ1EdbK3IZfuzzuJSnSOW
TrRSgVOlwO1XnT4WwGpSl05HXes31Sc5X+tCcAV4p5JE0h9cX6LX7jm+QZhp
KW/S9ZkBWfzvMvwP/aznFryKvzI3On+x9apGl3wEptkBOYe6DyCWi5cV5nFp
cwpO6as82CLJl5MilxLbDkfOWdTvk5iyccYYJTH6mBTq0MPFuEbxHJqjSudw
nNgP6uEzy7BeBZY+ITIQDt4SqkUOMROgCZRJaJFOQzd+wJS/ZUPRj8kEuLgY
qvHmkzj1Um7AoUDXQXUUi1w7hJc+gc+BUwFNiJ6TSYC8YkSzZjAas51hCXSM
TVok9wk8/ZBEE6ChXvkaqhFrjgW8DkwqqMEifUCChw6txvn758GboWaJfv7t
S6yQbj4c//HHun5+weRJTke/DFtu1MxJ94gTudgT3/K6k2i820n8gF7y8OQ5
gCZ/5XNtnSjCruk3jVk4PoLO2qXnjG+tqQt9ukjHlEOjz75PEvpwjpiKUXs4
XtQcnJ52aGgFBCz9pGoAmgOl2KYs0/Lw85NjSj8zG69poMA7/1QkkmwG96FJ
SbRMmu6Tly8cDEIKu2QtP030lsxHiBG4pDDDCBx8QLLbyZNP4Z2EEs8rEkow
cb4A2HTuFozTGgJhdceFRB355BY1l9k0KdIpXd3kZLgfj6dpjk662nofyeC+
FLiV5sg4ab3B/W4k6XVTU4NHI9mE/3DiX6QD9CN9TMccVlSgE5fxGpSDQ/TM
dfrz2peyHNscZFqKF6aAzEcy7mS3t25wj67Bi+ALa5w4WXbtXgKs7rMxE1ct
MwJAnwEBQ6vPHQY3CQ+GxQpJTUvJnuCjHh3gIwQqZul46hUeua2xiXMCHs0m
kG/jb9qNFhyeYHCrk+pcnVOlfCI6y4oR0TCDNK/gwkin02SMJiBEv0WG/suU
6mUaLz7yVYIMBP3UARjdxGKxk3noUWMlOXJrmJnFU3tLr4RyvFspEcxKsEfp
rUW1O2ANibEbjZaYLZmtMbAgBjhXxaLILMVzukR0TvcpcGsYZEoXH+YrW2Lq
m8P8Pp5jChwTNcrGsbaHYlwn1BRCZbugUwbVMf2ax/JN+2QV9Qa9LjRhEOeN
azPOlw6jmawT4auoDc30nuWMktZX180jXe6T3ba13pQNHXR64yz4n9MNZYJj
ItXP4kW+mUwRg4Y5SPG2tMFLig8cwgSkHsPBahMztU2dGPFov7oeYH5wInJ7
aGvFb/Y8O2DIIrfalLVrpg727JRdQSKEQsi8mYGpS8c+zsTkk1KVMTJwAGtT
EIELi+nm2jdGfwNXJQkHY7xzBUAudreI42HOmR27cRssJtL0NoCN7tcl+eF/
52Mv2lajnh6xto/gnVvOe4Vl5nwLmM3rTmEYFBphaSF2RiQSQ/go3lN4fndc
XUlFHQN3URbRTF3cCW/foROHSZYy7D3l/LEx3y2lrk0g4Sv3CgA8pcdH64bg
6tbAJiwX1eRNcTkoy7wsUjbp4yZgjAM6TnAoKdXlKiYJyBkfc75xpRO+lHLn
VsLeAC53Uh9+BHC/XdrS7DpjdIWXPmSqMZNtlNSQsIJQHk/MXhiSQx77nASA
nxhhespJFo/N5Q4j4BXI3vbx+IEFovfnHJGborAvmGakKV2y5QzYASYW+Qw6
4luTpugEIzsDe1MklxtAczwk5/23AwAG7Ph48uQUwZibeiLDRAymlfW1j4/X
Ju/q7vTy2r6Kyq9ToU4VPylvzTqpV1VKs8rXgXncKG4pEQyPv73n7ytKx71q
dDoR/Leif+m/VWTf1/63ct42oivs8E8/mCXs4H+My/nxT41oaL5aeV0EvoX+
R+dRmMU3NbOAvwNnTv5Hfxa22O8q7CLyu6j+cdX4858j+M8q6X/MOCaV/+qn
4KP8FW0tg/OLZsHgrIbFpi4UFt/UzGKHHTmumcXalzeLMnZuRM0Sdjq97n5G
Imu7+AonNbKz2P4lj3td7O9GqPb54vsTZnYRcn3rypnIbDSt24+NvJ87Edfs
+UkdZSEHSOoY6te2tSFAmAbBl5EbRGoNfZR99p4pBa36TJ2tYSy8Z29C2V2Q
3g9FbmOtrLjbDA33uEYPPxCezy/7V8VScpZerjKlLm3ED9pk3Zxsw9RWlEz9
dEG5aXlOHN3Ms+OXdD+9r84DreoEnBm7aXLlWScJqmi1VJnbZodZqYE1WQDr
+URyTkd7x1TWpdTpC1b8ceTkLafOFmXU0bcvbSp4+OLl0Ql+QZoy1PRLbCeq
0aPoJ3iOpPZTEW3OJFcjq8pRrIdfO5LB0erKS66absbRk+PODXCKw87VcNi7
zK2SDlv7frWsG5cn1UkLQ5dR6yNMq1Ujq2sqdDNkMwlx6k7gmvX2Q9Ys+UQq
EtevNy/1ir1JlVmMhhP7DnKVnzCTVFpUKamdWm7W71mzX2AGFuzVJGEh+d51
4MJEUMqr9wGho0GWYujq2RBN+g/xZKmV15zi2lpUgRSZIJgkj6R2oe1T1tTq
Q2UhOA8VW4O0tV6adgGgcPZ+tlcJArbGL+2QvIepXF1dLt88yBO7a/YumMsP
/wsINOMdHWI1wHAB4txVirtQcALO7cY7seFSO5xp04ezQUQYxoJRi+v9khs1
jqz9ljPqkxSgbteawPoeehphieU7zRicJ6YPGRh5acu+t6Or3vsWITbWhCcD
F2VTMOeTz+MDPK+Hkg+justyrL2ksa7cjTYcjsltOpmEiZKxG9dVfl1J8tjA
s80JwW32fC4ZARcYoRyKzrSCy7OomWHl2iUeafkqb4tvJsgIH2dIyuH4/C2d
/a3VDuuBGQJv1o7wCIUEKtNgp0PnhTfavjY98wXJHuzL7cRzDPDs1M7P/sN1
nVTwRFU/eJ14Hgk4Dw5mM6p/+uj87D8sfNHKdmwzCK/CEcs/O+mGzdPamYnQ
/FNVZ3868KB0ICyS5shscDJOtxM/7yZJW7aTN8eHb07cTqD16mvNxFvfGtjU
fcI/7j5hslHdJ3N67T7xzy6Da/YpCl+1GFP/2sqJ8EtyonhjHURvxERqOTKX
nlgSUlNspcH8cokP9QhFRflb44ZC/J9PZq1XhJNGs+8Qy/UBVeeobsYemaaa
3HuxLXw6KS1a1Le9fv4f2OyeIp7SQm9Otu+wd7lYAjJOMiE3S6lHUk6nTrHV
CgambGqmoheqVXYM1i4HIfQSs3SVOugiBz8y3JabZQ/uyMsBJ8DkqZmfmsz8
I6uGKTWdsJWLY2v27zhpwFjRTib9wEJp7d2SeA31dFLjCIelnUaFoUlNgHe5
4QPxChstMklgWi4/gBk3uR0pZGGDsDYwXWETqhyEIWrE2CIUyJZNmQtHZLMC
RO2S7YGc8TlOTBidNoV02CAEJ6ObyYXCczdMJ4XdYRYZENwwy5tboCb2Ul/G
k8f4KbfBCVjkAfnVNmcilVQ0OIRYwpgfVl41UpmNs7Qgl2N/o0kps8oJgG7J
pyE24AZUreZGLKNNGUsoZw3r6cWqj5Yb7KbXbxuTIXUZWznSTbbnmGcMn5uF
2QSDYEHnV+Y1ueA1DWMISKo1iGhawBO1ce+B68ylLPInPJN15XoD3tDhs6g0
kKxZGHUPJrmNNMF8r8StwyHIsEQYWlv8fJRFnLPHFPp+Macj670cRJwDkvsj
Txfea1bdwsdeX5yq4NmA45QAx0pekyUslpFC0YAZ68MxGhTFXcRNS6mTo4ns
5zYEzREF8fhqPVmbzug+foDjz7lj+dwxR01bmywEmuREJgqFi8iatqgwl5Qo
QmHAObKloZjw2bLAGOul9hY8VG2RQcgCjfICHjm1sBRZS/25dEnEPlsljgWH
3eiri4om8ywj9ywPfrfeOiz5qGhvM8yAVE4SSexuRkULFEP5YJd+pFrhWCmN
0jU6ZdUvnermzSGw+H5Bde7oA4alomBJhe7wehrBeb7LFrCfU42QxdF6MpWZ
Rd+2ZJMkYRphkofVjsfxvLDBtmQ6NX17KZfZFwVNDUTVPJciEYAFDYwOAzr0
4D+NP8K/AUo7FNpK4h0g5rjhhKDsY+k6a2g0Z8l9UQTFGrUB4bsajPIiSRYk
RlqbjiWTbVQdLBdkQhOvVXY4yGYp7CJaj3jR72aJmxQUpwULNITQ9RkUr5N4
QdYvrpNpHUNyr5IP+4SJiqWUsInNbjBOsQQua2IE5MsBzBqn+fr9oPNBfyX1
JtAUIJBpfu/QfKLLdaIjEjErONI593wdSVnjJGSrqFxDDrnqFGXNrqj5kam1
sQO8QWlnmFewnaG2jBRrFC6KknUnouqTnNn47IPkDf4AWH1JYaOsnQXqxRZA
miMnvMYrniLW83IIpJehzPRy9qEVmThb9DfRdjRXATyZMO2w5EJoId1mCsUP
+1K0AZ06WmxVesd/vZdJVIjn24klFX1awbP+p7Vf1crTPIlaedrOcZ08bf9u
ITO68jR3krnVhf8UFsQufWFfmXbiy9FkpAzl6GgbOfrLZ/J5MHH+rpzdQSl5
jRQtP/93kKIbmZybqEnkss3EUvJ4SzlZqY5LCmbbslp0dgjlRsHZ5RW/UGzu
IU/JZQTk4vZZcErgILUVPBUol7AV/8BZViFcu/REyLzyvuJdIwI3pQKfGO8Z
iqYQeo/XliFxgdjbVYvIJbPo3sStxni6RJfWyRNXCkV/ZFYxiw0DrgcnOx52
iTUmlgu89zGS20rWVJMtyWf7mB5/lAH7+puxn+ANGMhVXIFiIf4nBrJm4/Js
stQLHdNXwIqr4dw1ph9/AM0nIRItXry3wS10OQCWUdgkyr8vHjQ8J+WB4UoE
4XTmPc3Zyo+OvyN7EumgYYjJ2C2x6AgMdPOK8Ymee8X4eqie11QzA4PrW6+i
74gbbtdH17+Kjp+TCJBijdGTY3leKlXCpAw7zYySnXZbuUpZJtVGYfdLMl3x
jLV8MnOSzOkWWaV0jGccEDOPF092H6SbQxpZnyeAsVjkAdIRmsW1FvO2XeTG
nDHR05fNOvMYjjfZWbs4KdjMx3gxlu4pJ8ikSBZacZgChqhL0iDRdQ2MPXpq
ju5TEDDHjhHrFASLo++/E9fqb18++w4ZMorVIK9YEEYBw9nGa0v0SjIdFAg0
fwo5ajmmnzyZIks5Utpk184QMwoSjSjKhfMkFk7Bp0Yam1chfqTypLzJhOSi
D8FOSZR6ijA+gV3bFBmFuoSYj6bSUGqZZmOjCTLYZMSOdNZB7cEjglPggANT
og51lvSEEEK5myepKkJlHk3GGCf5jPo8EvWdRQ6RLyOPzlz1H2WrHtGLl53k
0x+cVJp9/t/EN3AzBfoEGCbv3Gf1xquqGBiHJbTaJ8scUnYcDHCD+bCLstWe
XV2QrOO4bXtWUFK4SgCMPk7xSU695Tp1oNV30RMUf0OawdwLvUGKUe99zXlQ
AVwk2HgazIxjJzqAA2if9H8UIfbF0TMMqODEXFQqQlMeSaqkJ8HT0srbNimR
gnxCG8YSlFyX1s89SPKtlX5+RUFSTZtOpQvrQHH0TCvCcMQaZy32aoigKwhi
jPFfpTgQK9vI/MQLgfUq71hb3NP76uhZDH2T196r6OfrC+RC4I8XMeY2PLUN
b2xDIDOuZyOeBwQKrAqdNsidRPLDzJJPBSDynBk5IQFxYVwJsiVW+kgTf9S+
HXVkR91+WLx9vJF1YKq1UteJFXZrV7B+ATYfOkY92fRNrAUQ/aZsU4dJZt9U
wxoluulBeiSvMP1Q3Rt+//0Hsy3ixvKDgZgvXIYZ+qq55Mq8lZXF77wXfu2U
IFAxpaLkXamZE1xfCote18z5+PWaiUfj20Hn9PWA3v64vtmBK8Z63x/4MPab
GVdEIlpMCrh4YjDPsJktoehvZlhO0TY7kCylB+U9XzfaCukCIGJWBmfF2syc
vHSUZaAEyBWKVC+OKiQpF0SlmjNrCzZ841A+vlGR8AlxNlepMmom0x2RV6bv
KpywAOLJK+2q1P6+IND1J3FqJnFTfaXXRdGW9IDOLelZabwLFwhNTYfKB1Ql
g/fjz5jrVoErkFXEsKC3aDadLzU0FdkEjLaiEg3IBjUNVSSmBkDgaBnb0SS5
LeiLCNfVCriQs/4hpaZne6hX2BukimRyq3pQmUqRzY0NCTNIUuRADEQX+mRD
mXROvRLbzoXGN8ySov+caba60TsTu2cr4WnmApSXJdJYMp+xx2KZg0FJ0udg
DvX95cB7ro11+XjalIWPYF4Bl3GGUq/EbjNGezwRJ7wTnkyZFyAiS+SLZ7Kz
4lIwQ7vnLLTB1DgpqnGPnHNdqZ16xl/s8arQfgoBVoqx/mP5xZ1g9TZEfHmt
/1jXCVx7797++QhO5Z97e/7Hff/jxk6O8bHTPf/jvv9xYycn+Fh/z/+4739c
04lfTerHH+o/wZW3Zir6mt3n8k/5U+3rsxV5bKSVTsoEMnhVPODJRdDHeu+3
KKpzfXMf1dVs5YPvPrdi/fiB13QNf+ZUwnIrStNlvarQ/hpOzOcdgkgJfkuZ
q2HsBx3RKIN1Vvayx58edHIPfvUD6vMbo2L2fMTYQczRXH/zw48//PiJ1eOf
dHbUydUFdKIqZs9bzXNVOyh3cnVhOjEzwVrVNTORMtZ1MxGuqQ4mluk76DhT
inyY9IdHHm4E7K6/cWQzwLf94bHdnYMSJ1XOEl77k+IJIOqnL3UgiwjfvzGJ
GezZYrekJcXPOcQ9dxOemVcjqnFEK124NZyg1ZHQsMpareEDyURtpyVXsVbP
HT/N4qm4OAFHoP2RFdZNjywxy3y5lcQ+pzAmF3HEUdiv7XaSWGOoipERci2i
PSEvFGY30ezozMfMkg2auXH2d+21FZyK8ZvmBffaUW+fB4ObTGVLTklqTMBE
2Fq+qoYcnmbiAWNrlc6ThYrCN8l9/JDiYzUuPRgv3jbh70kyJu8AdWogEDGP
yQBw3AD5a6eoFXaCd3dQZgo2hrxPkk8klrvZWcxmkIqEasm23XS0xmhdOgmC
zTwc1YQqntABXhwJRh9xGJ4yVq6+m3H55sxJFWE6t+5kvjIzyIRUyXH62SeM
x4RgE1z8nSMD3XgMqyxS8q4g9K3CJJl0b0/sJG0r9ggTr4sVtpafRw8hdnmz
pZoQW8kf3cwA7RucUt1HZMLe0gwoexev6IkSnJOvlmGYc/GkFwelPR7/aI9t
+2OAYzJCecMtJ0bZCQQ9DW6yTonrwAFOkrpedJhxEUDWT2BfwjbyO9N9pS3A
wRjNTMoNgJ6TDOJTgR5sUoqNcE8eV/8s34XQbEDoNRDocmGEs0CPSedRSwi4
MQoezhvjWQnnzQhklAjIPO4HSJ0T6xdUj7a6+rhwKtCRMo2OT7y4QwfUT1Kr
y67YSfLz3ASRnbx8RhUDFOqaQopXM/ZMUTQw6XALLszn0G80WRp60FyrJm95
26zGTYKRGDb3WbLdL4GJqSwl16c5YE+IRXEheTGUNMe2vLEFAOupj77//tvy
kj2RKyjYp1Tbbi7FjHuesqLroF25g82Y555fiwn7kezpVKG+1pDbllxbXCGc
yQ3CCeP5rXLTdXdGjNDc720/XnPNdaIZdsp5WHI3hbirZOkbJcsI7n6jeXFD
7tbdFNXhX43aPDysSEIT5gSFXKSTUt0NxphMEswSgyCaINY38LfETxyeaxEQ
SQ9jL8lRvFhwuGk4y27jfYY/JA+pKQtQGrbtsDP9djWDIpCocgfmsDf02KYy
A+OMwJW1a/LioDXuFuO0EFUX2bRBsyc3OyTP8R2Z4NoaRwd7PzXlRYR4O6ZT
LCMB29UgpC8tvmG2ettdRR98wna6GPBA5gllickb1Qtv21wX2ilZvM7//v6f
P70b+Ge62+gZ2yqmQ7ocPDxnS7PaFKimZI7lNnsXl53nLdKPiX2hbUia9l65
7Db7mJkNwyWx/U4OaWlpuqeNePxrjOywTQETV6SZiiuyrtT5CArRH3khZj00
pzNdQPpGyFwxlvhl534CJMMYY8g1u1nUa4e2evm6BlH6hAoIq8RpG/D/GQSw
qudYT7P5OVbFVD23w/R/1OwuWynEGnaRbz54ay59NDOGWeFE/77nf9z3P+6u
PCrpeKo1RV+mCvpiHdAXKoBk9ttqfhzVi2h+AhuS+9pe81OyKH2O5uehEzpp
mlltr/n5xmpYPlPz4yp+vkTzYxQ/X6b5qYXJF2h+HN3P/0XNz5erfhrRToqf
lsRB1Ct5RiUlT71mp78u0TQyPnSFFAmbPUTsIRexhL0r4Y941wzJ/AMrHqDP
VvPNcNAirg0POPlzxyJ97ucNTZsotxhZ2zDzp3+XoQQLHJxk/JPH4hmLH/po
gz1IivsF1tCpuGe70U8Jyw6edqkZuKCEzVoNR/9kOBMraSAXUc+KGDbzJhG3
KjZb7Xkqqr2oCbS61W6wNsbJsItKq/reRTViHOm6mC/UcHr8a/4Yzxtlpm/D
vB0lnvCRU2u8HMdFzJI6sMiOq6vj+7Zf8vPYx46KbISBQxpdqmIatH2Dhqzr
4c8D8o0aXqN358Cx6lE/UyzQPWY9k/RgPIZKa2noWoTzR3Ml/SRuRqGLUTIn
gYyT0jHoCpgA8eWGwW+UnZPErm3ERwfWkyz7uJw7yRBZjrEhXsXkqTHJHjkf
TGKkC6QalJMNM0ifcxQJ/DXV3GRLKnh5Dv7E+JH6vV3LFUeVwkDUA0m33eBo
Ejyg2/RuyV/5TLelPhymmmuIEdlmAPSDdYKG/qMV4gzRV7jLUlsGLr6ZoKqH
krsDYl2s1bhuq24ltl18Exomu05u3RSCrO5/rNHQeupZTc/I7nt1ylpCJfF1
VrfWwHXgxqgkET6YCw+nNBHPUg+NGxQ15cT9aYpTrjwncd3OQ5UaPckAnDPi
cj4fTBSlsWul/Pea1UcTcJOvJragoHD31wl94abG16RRnFmSs6eivPYgqamx
G1MTwVQ/TI0Wz7pxUOJM9bflaVF1QTbrS8BUVY4SL+XpAyVJxT0TF4iknMxG
7POPWcTrQRTG0TnT+CLxHdBscnJZvfq6SHpzAhJBhPpAf1NNQYnJREeux4k0
oY7YS1q/Yx8Zehz9zF/87VJTnjjxie+HneOT7otnR6h47EXwEDl2e/GFtAj2
trYp6G3FVK4ripMA6ZpSHy8o3NJmvuH0vOLn+ZigZg6Jn0k2ix6e+X02GcO3
wA0tdd/ZLOD8iFiLWUFZtY4rNpePF6PccspsaiqnKHqdPiSsw8P2uFTKAWQT
Ndmn204hPz9HVL3HkNp90lvsW3wTvc3D2rILu3XajYO0mnq4JtMUKzUxxJbi
ZiWdmQmf9YQuXF+eST4yP7LTTkrojIvvNUlkxYaGk+tyNks1ewD9sFG8OfFh
GEUOJ0AU9sFRyTmM16ATKus07DEoDHFHO2bzAFEIuUnOLTjuhrjaih92RTaO
AQjoqBw/TojAMeK0jjTXyIt8lM0TsSI5Sdi6NmgXA2OAhZqNrac+nXaTUK0d
8RmwKalGN7lkpPpXihz2OB/NOzInTUR1bi0OSs15ZRSSzll5/fBQWARc5/gv
+kK1OaEqYMMoBUaU00iMsgVX5qVb1dkyLpkZpEIrbRtvKy1REsWWE7mXueyu
56qncOFMGXKEhVRSjifAUhN+Ee1bOtbHnMH7UVO+2qcivJj8ipzd8Ftcz76Q
0YoI5/dXrYC0ak05Lepy5Vw9G7MSeznCnTT6ltQdAreOAeGmgM3mLrFYgJ4r
zgZNwF6bEFoA66dLJFLg1KjgfGYpDFGXPY2s+mSKRaO+Jg7gjhQoQs1xcCLS
iDebMSBq8jIQd1oaTYVq+XVTwdBgPl5mcPlKL0Wdgfosenmwa6ZiE6tItkY2
vCzGRKmRFCprEKbK5tEoBSb+LpGASO7V+c8ki9MKNrWNzSBswb5LZljdXOJj
CudgtNfd/qR2oGOjNzyhn7K8coj9QI5lXk/eu9GQUgvObIdol2GzEhMLcbE0
RQjoTMLJ6reEad10nOGIeceZREL5dp+Zz3uCblgCqWvYxzKj6SRTQUJuLgBO
yFgbVUMcJXnHegkomj6RRG5RQYq903MtuoBTjbtS3pA3Uk4Nh0W12ZYZWKx4
ish8E7cVMiok6rXVzRZvIimkRRIkSB7YqvZCJ01M5QYbv20DovEykcwXVxec
TYQBa6V3G9vDpbIKvSRbtHepXrgUk/kksUF6JpFx1lBXMhR7mUOIfkmVkXcd
XH5vMknZPOoJO8yu5qRbI+pIVi9KEGAiTWUI0QCksxRra/DzuSRgZ0s/TBJB
KOyEZFIhlo4B266HrEkxIftE6NIDueFTdMElXGgZ3V9ef9/9+2DY6w3dWFbj
FMSaMpJhgPOfk9Qh0u8agcQvcMYAQWnDpqIt19miq1pFOrE1eyt4hTkWgVNd
zphX5SuFrVn4PXEz9hdk+7CIlXYnElXYqzGjGwbPDTD2qprEU5sDI/TvKUw6
D+EXtVKY1v9qXhx1Plg1q2PxN9y3XDe0jsIOibVxdM5B56agWPPqpNQ3wxPj
S3m7QtCZzc4TBQ7+dss1uKIEBPJs4cpuNlgV95KS55jwMbLKu0O4deWc700s
RDiddkDecl//gOR5lKQPYnGWfEDCu1N4w90swyQ1xhmnbOAsHCWhUPbAt0Lh
LgIiXxmEr3L0pfxGyAwQx6AF47m8ROS6VPClwf21uaZO4QRJ2ic9fkEpk+Zq
rr0Lo19YssLEt0YnZZ0ak7GT67XpUSsiMbib5oFXXG4dj9Xby+x9S1O6OU4Y
rDLiq92tBm8nHlSC51R5yvRsXo4JSTZq1RSZ3/FypPF7cy4fdkjWAfiQs5VO
c72IrtXq55z1s3fHMg8EDN3ShmO5YRYPpXMMoqV0xWZL/V3apq6JZKah28RP
TiOaYMlIEKglRDHklbHy4CmD5pjFFnZz5Oc3b9raM+0KRjWeZpL+oZ7HFT1M
ms+RZfKdA2Bq3vFeH4e4++ugsouusYVhJpYNL4pz64bWtK2tudRFxAZHJDbO
l34f3YqJeiuhBl7MXNiF+fTe2Vt/JSYE4GoYHQWmQMmpUzuRrumidhb8w0ri
Qly6xSUmxG6673e87xo5JVAheMR/eMOWrLZeSO2OuEZzbxnH9uENsNhyIe6O
HDu9HUS7LKRyFqt1CznxFlK3I6vtF1K3I6udFlK5I7i6Fj3IqOUt5Pm/c0dO
vu4ZsV9WLOTF1jsSffmORF+2I6vgs7eQl1vtyA4LcXfkeXBGtl/IhllULOTb
/y478t2/c0deVO8Ivt7Gn2BsmEpfyqDpz1vcZrVTkAYb7pEtXtWF0fe/vIud
XgeNi7AkjcutlYoOhg8A+1VbwgZfzarKNIaFpMjEas5Ng7Lq+DoXDiX3nYCz
U+cdFnO4YoRrU22WhL/W+tRmv9wnRidVqpcqQTwmutgqinr9Oh2ZsWs7IdS5
2sDMCOjqTnrBZioxZtaGo/m3ahh40iKR+IoeBx3xsqeQG2bgUXvmeJ9wDeqc
RqLssO5IRt1QPxhFFySzMRt4XFk4q5EwRCQgeyNwjtaUlC3Su3RG6Yu0NPYi
4bSbHHM/HFCZVdpJU0BVZGpR/ZYUCC032xi6CGnRbQIrO/a8bJFrO1otReQ2
w1RoZylv2K1qbj11MFeKQfWApCVFiLLvhx/rHklWWcFR7hgzUGmR6X42bLk2
QXzIm1q77IKhKcXXlHORECWtdrmhTKTjvRk+oPKxVGVKUB3Cnv/ePpI1gAGO
s8Pjqisfox2NK8GLDlXLcTpRPV482tELKYRUBXjKXubIfEdaNQm3gE2azvMs
AG6b5LSUJWQzwZbIUF66qXG2cQyT2HKLFivyIVwBZrzvryruiAOsNOj9zxtD
nHYxD6TM0uVh/6Hr8B8oVd5wVvwPbeE9YNKDij1x5cyPm4QPmFygpTHw9Q/b
eWkMO5ewSfjApvw8/9i5Rc0Yg/iJagVVtDiMwgcaqyZlAD2kdKCtsMUhPBI8
sH5Wh3Wzcr9w9+Owdh2VY6y4wS4tDqvmuT3uOmcw4ASOXujljxe+ycsWnbvH
fs1l/28mB3QH7EAOSsdo2xZID/gYbWxROkYbW2CtxHfCUES2yOqGFsKLRDu0
+Em4EmzxP2TNzCVs8j9krXYd/13I2ssSWaPDtC1Zg1lc1JhHb9DwyOKBeIiw
bt+1bZABiIwrOTkmqylqlBhXL3IVecy0J7FBMd/c53Yge5DJgjjn5nfWRjPK
pjeS4to6sqjD2Et5/uVz04Bdrpw2OFeOVCDZxdRcIletWyzuIqZ25AQtD41O
g3fANDop/MnIanpWWem2ELdYkAXEDt6BQW5hnocU1r0s9LNKb2qHCF1T0xkF
R3TQsaejwnJHgvnVSa3Eb5MbkO+/K00m3HlsfPf8IGYWFWYzY6EqC+9uWmFj
DKu1GnZ9X2KdxqGrJLhHqyJiU2Er36Do+JixHXMhtthXkUCD2HYAIn0AEKCJ
FgvZyK/nuHpTgla9y6S0zVp4OvmuEUiE9Shg6biVfuqlxZFBUX0bXJ+0h2yy
nCaugkSlGJDNxuSn6RYJQdmuwJBejISmrdm3nroy1j557qgKYIQWP4QVYN6+
gP4ui8W1LpUaYbyWYCjKWE0hEeSnKq5c1Gt8kz2YHH00bkyRtGQZReegRUZm
4YxSFaizHXpchilq6Tib1A7LCZodKRndpkB5gVNbTpskDiHjnhOPo7uCzjIj
Kn0yAVxGF0DHi1kTlMozHX0GUxWkJuHE2AEIDoCRK3km7ltBZTQWOGMKLqHU
3XyCupTj3oYSKzhheUgUGTuwnNgMy9reTpZIkog8zDzw4/PktqAm4ARdcdNb
N6EK+hLlLNKzzdMUkpHksFgPJJkB0epktx2jLzg7y4Ytznv8kQr7YJjYIVnm
buN0AotH10JAFnWpysvonFv8CJEjt1oanid3Ia7O1hj8myaCsW4YaHefYuxG
zsJ8UEOW3vlVZGc3aecpxn3UGkxR//L6FZz/qUQ1XSLGT3kLrxFfxHv2bgmD
wdWH2kctpdPSPgbYxyCJP9Y2n8af0ulyGrZl7xO7DvEW8rY2dNPP3E0VT2iK
EIObmhQ9b97ZHsn5zeTktgEHV8N36kw27Ks2yOKVN6nqNAj7uaV4XLyowjud
M6lnnEyG4oR07+RON9twtDgeqbG+Q0QDRgGaO8kWLSYiXEBrobHi76U0Ns5t
itFON3EO0HIfLWUt1Ywrx90Tzbly/PzbF3hFcqeXRSQb4eheY/nRFlVaJPEU
O2CHd7MTpEDLKUrSyexj73Xpp4m5fh4R8QBcHDJFVHZM3tF478Px06u/yQen
4mEzZ9O/n4BzhHUTE74HJT6L/IPe0QCRPye3pSTEVIrt0V6ERxOdcB1AY52o
tvSToWIVwYCuF8wcmIQzyripIhOYJtE4AgFh78AokrC8J7ivcIM1ksek3ddZ
qU8WJfaiopcYyqE7pZ5OVAzvDr0xs9k+oBdyXcHEK+8f9woS7K73UhaHK7gw
4GaVpC/Gk82FrdlJ8jPTLfGSiMKbJ+aYlze/ImNBQatCr5HRkeWPl+TIQllm
zAqJ6Bdcb/lJKoHWeRnpuTtenMC5w7PGhw6zt288do+E1uS2SX6kQQW145ff
f4dxdqQ4xQjaKQ6PcWFwsqRwKDEZpjI96l8ZklisgLhulwTiTqq7O1WiMP7r
TKto1tIrMqJY2y0R2kKvThS9hkdmkmRMugXaBRCBDfEe/D8J0ij/Sb3MafNg
VYOgzbUG/fnskPNYb2bIJYGcqbNLK+m0uAAhRmYeM58h3fgATkUc2TfBmbew
8Nl48rRPlKcwJWFgoCxXEClXDAxo/JH3PQf+mj2jnHLfmZMphpiuZv+8pYiY
UEL+rrMa8vwSB3kijSA/YO2FRUlcqmSRpWOX5eToVEJ0omaamkah3LzDTTXE
Z5x0DGfJpwPvpoLcGwlR8fCEfTjua3yoFI/ssWo+EUqwFzURv8qemguiyuzg
uU4W8EKgyDRB/qyhfcnkYcRsXkxD2MHfyRTncAIavpaMre/sY/xU647XnGVs
1nLM7KE/aNC2tdaG8q16v1VoO02ki76IqoqB17G+B0q8lf68MlqtUPu4Mv/Y
P7WPDDc/Mql75ME8ktpHPBXLDz92OuIYM6rrxY6W4J/e2kfoT7H2kaPNj9Cf
uO6RiOcOb0abe7lf+whBd7r2EYJusvYRgu4s2gjd9YtONm8A/emvfeQY/6Sb
e1nUPbITdJdrHxlunstkM1y+Iu6uf6T2NNrfTr60l/WUwXusTgn6rSpBLyUJ
Cjt49IwORVVDuzl4sLLpnV60ldomJxZKWQMh5aECZ20KBHGmmGKGxSJbGILv
5YrxBKEguNOyA9tprjhyg8uI48hGG4LqMLirMFYKuWBU2H7Q96wx0vAsuo7x
X/Vm2HUOsAlGdBQfBByWFM8Ok+ZJsXFt9+SToNJZry8htuMU4IPbwFzn7XJy
i9W2CLZ3d8ibFIkEGkTie49jUwLIW+XCWUTEGBYJLxN9EDq2uNyD9GJkhLbL
gGCYmQLIqDprvWAcZoq0NLCilglIRi1qkPjYdd4qAdpwnkYBgiubJJhkBAEd
hDo4yjEjYvRmTxg5DX9gKse9lhcuZYPJWfi0lWjjOwnbIhRzMnAalm5bEKkc
Vr/3Vl9GJgWzl65qBmdHlcddSYgmaTMxrYflPDEJO3RhFXNee9bZe6aiNuZu
2ue21iFG84SVQbBbEkNQJuiI5JcfCq+WO6SiSp1tuiQNcijZxJJKIhlrrPUT
BZCww5HDpav21kxG/cxISCGHMgNItNL0JOULqTriyVNOOnE/w68MBHIKppRM
82m+OW+AVPSwJe1YMa4F1r579lJNK5YFBqlM+WPWTO1MW/FiwT5DiUDq8nnJ
BpjwG8nYxOZIii4KzxEFf76cmpQ+RKRsziE5ILw7uEDdJ+7AxA62VQtDXlmf
RokIGppDjRT/qlQX8byHukW+USUs1mqCMQQZMQzbWf3OIvmVU8iLrvJq2Iep
ziZUq3Jmysq4lb5zU3oWu6JETpGiGOX3oEqOIIHmBYftz0FqnM4510QorpQ9
gUk8gn2cAzZwcHjD40wczmPldVE2yW78n9fPClg+f5yK1z9Wh0GjyeZGwYRX
xFbu0KaH/462aaN41SEk6Bx1UNtifivw34Rcxled2hf6jauCwvQz4H6YASy4
/aqmnIudjbOGGP89Ii/tNWPvR4erf9hGo8hw9J/xP9vP/efs7vQzdjf5jN2d
fe7uHn+l3T32d7fzGbtL5eWOd9zdNPo6u7v4nN0dfcbuLj9jd9PP3d2Tr7S7
J1++u/TvyY67G309yuyCdJ1w+d0m4XJUL1zCoO/o0tlU9c9mr6KGNoOPE1qv
N7jLZ8Wcp92PEjaqQLK6O4lTvQQcaFTknBk4WLMkbVLqd8nTlS3zmHz4nSjk
lo0Tpw40mOMT2sCglSZ0cUOAEhucUM4q6nr+Iy8+Zwauro6DxnbYmF0/+/aX
hsQcRDWdGJ5iq7hdQrcvitylZxvX0ebo3fVLPmhccAs7m265D/1UF73bpxar
SPwWgY0oZ/ktr9gbsfE9j2oDp/bDeYhSKAxOPDLrbrzYuJZgDP9FEWTPg7Wc
+ms5iMIxKtZysn4tq0jGIJhWxPCuBEfWrGW1zVqugrX0fS54tc1ahmvWslq3
lpPt1rLaci1HwVrOjO+r18fatZTG0bXwfwccy1sfyatrqYzuW22/luu687/a
fi2159YsxN6+VcG8q3XnlluvZFZr11J7bs1/VdTOX0vtufX6qMCxl3Yt4bk9
d9bSEgK9aS2151YnscVaanHd66NiLd/atYTn9sJZixPHunYttefWIYefvRaP
JFbg2Hd2LcfBWl475zbaci2159aj7PSqies1fXzRXVl79rd+rTbxD9v0UceE
7PIiTuaLw3u/PMB3U4jvl8X4VkT4ilm8JtB3SysQztymsY0oO7XNLCdq0TIX
Thox8eP08/hY1bfPqxM/jVouzDDGOYA5R47X2men2046Ur8zNx0PafUCD8SO
J0dQaHJYVowFpkfV6lERLtUEYw5W1M3P0Vs0W3TUfwimN8HiDeJK52SRQlcG
j3A8UvC0hhN7+aQrvYIln6aMPJDw1lMNb20OfjptqW/N82+f//FHRUSreomU
ZA8NWNUgWfX30kVrnbEuOgEltsKnOlubDHnpBnFF0s52pA/OAW2mg3W5MPJ1
zAHfmVXBR2ewO5h9qXOJmDlCEPx0anwcncoK6MZe5GZlkiKOAfPd0bNnJCtd
wea/arwivTIjV5DoevPEo+awczUc9i7bEaXxQ5IvyaTbUVKMui0tesCOqwja
dDJZ5sWilOIcRVk0nVrl9E1iUs6zitspDXe3TMeYtrAk81W/QvrJklsFzZcH
QSbu9OzvW0trpQggQ8T9y7f2AsAOTl4PBpEANoLd0g6wa73QaucDV85KR+qa
IbvSgft5zQxWsJt/xrRMP+KO/vn5SwNB88VB7SoIBnJv7psLdF9m4H6umYSb
oGTDEuo7oCW8fPFffgnfml04ehYsAb7ghES4CI+z6+64BPzHlxpWtRlFDnyu
CLOUHCCnimq/v1EmORI5rKKvYnHlL/Arj9ciTlBngMfxNHJnUNlB5S5Ujl86
jfUdeKfxuPY0rpnBtnhQ18HWpxE7+Lp4cLTabQkHLh4cCah2OY3VeLD1EqqP
0w5LqO9gy9NYTVJ2WkLVa4fTWNdB3S9byhYHjVq+O+ALKqqg0yFS9tskNYEv
1nDdl+i2TAls4Zy94zI9CSdBoe6a1wn6rwCefcuBS5QJmFltrTaQUVUI9H7R
mFG2es/ZOM2lpFgVbYL4buP8nhKGsNsut2dp1pQ1iZ8aD/FCmGaaTa4Jheyn
dnTPpTqCCTGX7uSIbVjxRHl35AJvKIiKynIRw8teCm/SjyYcoMLXOEivUpcm
h13NOIVNKfs2LrnpChM1KXJI6V+bJcf072eyMZ06yWuwI4/ubE5hY1y3xlFQ
sAD9dyigeetEN2uzENVmunGFiS2T3QSZbtjrrirZjdNKEE9BWcQqV4igVNG9
JoASwQBYXSqlFRQw9kPP8AsvX7B4Ih0a1xc/dav6hay1UzmBD3X4ut6hpjKe
mQNkKGQCB6+Obt4xtJksTlXRzWLrQ/qyOT6axSjalVsb+CdI2aTwNj7KIOws
51gxfOGULJAHKQwijGaKfrIVE0x2ePHOMZaylub59laC3XmL6W4VRC3lOjZu
YNnLten4QrpRyi2XbLnJzzX+xe4kR70IxpF0jcdKM8lrWXj1UmLfQ9h2dAxC
by+knloqRDpxYpr12TLOu+DLBVQR+smoyVMiIb0CMBQw6WpS2Dv2SSJgqbaA
Opj6+ccf4ycbOXlNT+OUPHyImui/mFF808Hg8rpFJQIo2MdCopkvp+qJeCvj
4q/cA/quMuX3m7W67thud6UhEf1tt07ct3rbzhfJNF1OW2Wsp75g4yhZWQIn
ILm9xdxx3oPSDdfzQl2Gxtdy9GE6sy5vhzgjQgfcyuWU1IzGNdRMTCfgESgO
M2RHxLYbdFPCYfeCUJc0f18UWck7rc5CffxMA+IKk8CMU5HfkvmbgCYdaoyX
LItvuYc45ThzfkZRHitlsaPeTDQli4RI/s0TVabTniVsmeB+TnBvcU+b05vx
iahmFKsTAbmxQPL8yvDDW2QbigzzLbbCxou/EY/Ze4Ub3zlSjQwHOciL7BHD
sMmpNDmtbTIJm/SlSb+2SWqabL2W0e5NErfJ6bnifOforHZi1LK30ygacLTr
vmzdxIbMxLuPMirv/vGG3b8v7/7xht2flnf/eMPuJ7vv/mz33S/Ku3+8Yfej
nUahgKj+7vuS7r7722Uzizbs/smG3V+Wd/9kw+6n5d0/2bD7u52Xr3j2T846
X3H3T3Zvstson0H5o7UueMfPdorv2j5973sb8c+8qIQtMBsSjx/iWRHfsUml
XLUHIxiMla/MRbRs5Y8yX2eeFq6U4zk2MhK8+kqGhUu+lbgTCdV2WI2QLbty
OAbDjgnr4PMOksLG1EoJlmJDZCjZAnE6FH1BARgoLD2yLCFFcLUQjc/PtyOT
utfyP7w4G4o1zSSn0iVNs7aHCkYxgEWX8oVQlgm34J+Rb8julI6Kcqj08dGa
UOnyqxQ8XX5ZFmoDs1XizjYeOY8767JvBz8sTSqZLUtvVuIjtJHZqmqygdmq
arI1s2XdXLYmuLbJRmarPLGtmS07ytbM1r7jYfLvY7aC3a9ntmp3v57Zqt39
emardve3YbaC3d+G2Qp2fx2zVbP70U6jbM1sBbv/b2K2Nu/+yYbdr2e2ane/
ntniJlF597dB/n/L2T/5qru/NbMV7P42Tej19Zmto92ZLYxz+Mm5Pb9GTL29
Z49r4zHXhF+K+tuo6aligWqZuWqqRmeui800gZlkMlHFnxubqSp7Cc7kcmqm
4DpzIvFCfdGwG34E4ze9yoxsNKoOzyR+zUkZR0qkIk8mtxg7i6X4xNNr8uQq
a0u2oVIEKfGvayNCq8JBA65n23DLlcE9RtnPit9Z2SOyKWoJQ7M6pfgkS+0e
O/oeo6Ko15U7xHBT+RdxWDUNJpsKqJFJ3plS6k3p1JnSafWURttMqS5eUztJ
tplmZbBmLTT7ztT71VM/2hWa0a7QlCk5Mgt6paL3G6U9Kk8p2jr6jJm+Lww9
k2ttW9T1WtT6BsjLriy2K9sO2CPB9Y2jaIN7wXXnKwpr5SDGbrdb30UJOY8d
5EwEwzdPpC7WVHjA7TD8cwFM/x5vBrBFnf7XQJ3UznHtXC3qAD9IBHlrUIx2
BcVyV1xLd8W1wsG1rRpEn4uJJyGZ/BxMPHEwMdoVE6PPwsSTLcBvUTH64gt4
He94bLx/tmYd1/KKNgyxkkfUH6sSmZAnPRVJF1d65jXLj9bl1ow4O8sWoaft
tele2n52PnHmICWbG5t788TOHo6/DHriSJTuNLtBDxzt93Y540zpxAj6Naa1
+NjtrbKC76+cWF37peOMQzKQU0vKKfT8qCXOJIsr2kZtbTKJBiAHGOyksnpW
u9K9R4tn9fU5yexPWjbqUHoLtXDRBe1CDvvxg1v6Cc3UzlcvJc83QtBxmHE6
Rreen04pG9GmOlbQzw3BBzjkyTJPHxLgtDMJCeHVkceE77/ESlTjo+N5G7gu
aUX8ERMXzThPk7q9xyb7EU+mpgRAUXcI0KRM3aO+FXWnml7IFFkPNbXkYmGk
q9JjVq96o7jiZQFy6i8oYpg0NJQy/jYFQcLm8ZH8mCnGl3OiLU4O1FXdPAUu
SJSAONXUnvcgrb1NA2pyxQcpdnNO9qpui6PYmND1kElidHWSKpIpSJHo+LdI
EC/YRS1QrXPEg5MZP6YqBpy3lI4rA3k0Wi4ILcUsQJN+JETvuI4MN7htdWr/
rSpHIOhhIM8x4AYA0UlclwCSY/thOn2J4tGU+nISvXTcNSn227IbkjMumWXL
u3t2WpAxPAW/k5qNPB/mkmw499IOoe8SBW98QI4epHi+AUi219AusvsAbfjG
iP00q8T4qRLa5XC9vGfvuKX2ZfUEzfJ3jCwgKiPEFsktEgWOa5JseEAfKa89
JYTGiRinRc07PDhnf6AFnl5oK0RHCSvMCsjK4knCzHKmAzl6FllLku+tOXzz
DraNcpgtErg+f2OSAW3mMJPRkmNrjAed5rrFmcq+PCLEbzgnGpuKgsk4k29j
gBB5ppETIGsDGFJP2LUJpdLTicns1f0Lto7tLPAIrAXIEs/GkE/jvokoV7En
lNQcVTPOBWkD1hJMppsklE87o6Tb6PYkqhkYQIKgJLs9R60JjQJMpQoKpUwV
9nrGXr+jpMGkUGGNhnOpyC0hrlJY7aa8gFwrNeDsZ5iLfF6kUzrj+rCvrGJn
M0q/oE2mSbHA2D3eKIzCiycjr8RhdVfW6YxixxApX0OXmFgYrpMiGyFLdvl6
0NIR0C7o3dljTJ83NRo4ccyle0PRPGAUcklmTBSb93qBNKCSUaIbiJ2MK7Y+
HJzQ1yJrbrrWbl2yb64q0hxKuOK+yXBIUZxyhgSkgiK6O9nCug1StrGe6Vu7
o0ZS9cEoCatQQPR9Jsnb1fWAAgorFq0+4HSumdiartF1kBOiAT1u4s2N1zyn
+sOD0VK/wh5saH6PZ/V6+POg8/5cwgBPjp99zzfD8Np++/3xC6yKWSxnMySh
I0lEzZGkSuYEMExp4CJAfIr1inT8K7vRhb1d2zyPvd6e5LA0R8uMZgGOOysY
z0jNbU+3bYvhs+aa6SogLibJp05vglnli/uprvjkxTNYsQTxEr3C87SQc9Ap
nuZJcG45gXg2Ez6DvXmRXJCnOHfldMQlZQr0ipd+3vb6cGfywf7998vz8/Pv
nh13j3rnwK9S38Rijk2PNAyeJYM8Tvd3SXa3iOf3sM6G1CGRA22rrxj/aaV0
mJVvOTO3gVKACVw2kk4fv99TpOwYpNyLxnERU+0Yt2AAPv3m5OfBlfE0fssO
Em9Ort5qSO73R98dC5NOzx9XPX/sPH/8PRvYe5M8a1eepvCIMMU07glwuAAL
Ta0yPi8zL1J3ktwWmkGS9OOURVLSveJ1KyEoecFpYjnZazK6n2WT7O4pah4/
O34unrRD1sCrfMUxEBIxwjxJRdWvf2U5MibILyHqSgOi3tWXiEiayhMOzqVQ
m+uegjA24ikZLnh8Ts1K24Z2jjxXp+W254phMMcIjNhHHTlD6Ilg4wsuzZLH
TMunCdjrLdxLcmjsZR6msCKHf4rqwCBy43LTLs3T6aPyAi4DpRUk/zw+ARxl
WZNSVTqR3rFoEwz1Z6as+rKnxRG7wkgZG0IM1FbJFovOCwPGAd4/6HS/LBiE
5xL63Rz0z/VcvHj+/JnW5Qg7wGuZLjHjQU3cSYJh41wRr8urrWHaDYbmnOYA
M7I6MPV6FZwi6iT7oGl/a3UqtnIg9iCDUbrcG5z+ffaImyjnmcjsYgREraDj
XLWjHHu/PgWsZ60q56ra4qVJTKhwqDl4ok/bFED34wqe7fQqwlFXm3v48Uc1
Cde2XqstdGbujHKwaWx83ul3tWmklf/8JwvbNf0bGU6fx5dvFAl2x1nNygp+
TuuW18Qfm/fh1M61587VZpby48I1yNPdhzIkpWkJTqugm1LJ1orWrnp1w1iV
u+T3VvFyoWi/zTwQSnas8ouh2Oex7Q5qa7N94bk6KEHR2cFS6xABVpUzP3Vn
flCdhs6MFsKpDJyV+3wJ7ro1B+aveehg8x67h5X/H8yW4XpWEel7EI5bPlQO
XKu3fMPLzDxU559UBPNWqF6uE1YAoO74PHrPt9uGorN1uUDawV2c3yODwAnd
SWYi3kguUPSrrRCd8ApouhxSom9bwDuni25QwFbkihtHeHOvaFdgK4/GMjAr
SahiFwyAcBqck7pKcnt6aUE183sFP+g8S7Wh1kb6hvcrXaoSR4QqZdIoY9Wl
bGm5Kik6xvFNpGC+rRLnRXXiueh6NgQBiGcsoL3RogRlF19UxtuKaKa+URjl
23W4aeRNAQguAKpVdh6r3XbGth7a3vTX7Oh6r9/nZa/fXfJzkT/vqtuNwv/q
Died6Vf6qdc3P8h3pSSk2iAwO3ZtJ9UNVqWEaZsbeGRymwZMqK6G0ZEHtfC6
2DhCicZyg3LCtg0N6qEU3MWboRRe/Vutwd6hqyooHXsl5/H9j4bsbhjB4w97
3pSqoVRmKFfroVTmITdAqYqJ3GoN1Q0MlE48KH3WCBVr+MpQqt7pCihxVp/P
3elTb0oulJ6XoLQztm4NpSiq3Yf1J65649acuK13en0DA6UXX0aXwtdGKFU2
2K+4H+qSu6x2v4FCNu+5snl+1gO4JdFktcbWtms5rdo855XOqiZiKtTyVOvF
hPnwgp+CfOhdL5MjsVAmF6PJsFin7NJSJ6hHVcMDKaVqMjCSScNJwljKwEjL
dRgSSWxYwZBgV4EPhGVIXlSFIe2WMlSCjHZhS4ywsQtr4jbamj2RRtc7sSjS
6IIbBUltNzTqU6OVbqfn91nb6HseKUhbq+S5ptGL2umtafTcn97pVtM72WJ6
JeoebTG90h1y5U/PcX1smTmW7sJh7fQOTMvSfbhhevYfl/s58qd3Vjm9cE3R
euitaqFXz0OUd9hgeT0fUdOoHsvXNNqA5dVr2oDlwXCrrbB8VYkRAZafB9M7
qMSIeiyP/Om5XFI9GgWN3DUFWH4RUFw7Rxd69Vge+YO4+7TN9EqNjv3pva6a
Xt1IddMrvdxGu5Hl3Vgi06iCLapPeaeNdr0JQ+boRS1ztIkx2pYtcvyuBmKK
OXxrfK6i37+pttYQQ3VqUuVcO/4MEtxOzo9cj1CdtnKxHt5mi6mY8LPZQ/Jk
a7UBylwN34mChlB92Jd6ggk6AZDuhhUqNk+P50zhW9SIO+qc9Y0uj+q8R2d9
tR1lM8xqBnPKC8zpS8H2jkLLuLpipNMkz6iXWcSaIOnjPn5I1FqeSZY7df6B
h1ivhQW39ecKy9Q7yrXHNq9cTb0VDiVt43gx6Kh3KBm13YRxND30yaDJysxJ
Pef3f9bHvVjEXDwTnRdTp1w7dIcKUR0vh11AcxjnY+Kh2zoSqbloMJPZQHYS
/ewIEzVh2CdyKhuZL0pOxWqkT2ndmuMsd8x3EtOPK/T63gw+2RVEqvtYwvmw
ACYsNXpIk8eow30Ty+t2XXLRDQCnjgUMf9XIFhYD9AFADVMVsrQATIENwyxR
ICiDpQj2puulnzaUBrf1yCG1ZRLkfYuPHxv6U8n5VSlC6r4l0hcaJ/T5A/87
/egI9wdeL6vo6uKo540Cz/3p/+vt2roaOZL0e/+KWl4MY4lGqJtus+vdw33w
0FhG9Nh+mXMKVEBNCxWrkqAZe/7Zvu0f2/jilpmlEtAerzVn3EKVlZfIyMi4
x+CgtxPdiYODzZ0/mV7h9HAzfuH3m0vL78/CJX1Be+FF7YYXn+2FF+Uv/K5z
Wfj5SbgkvwlfEU2xtxcNhT3aTfdo90/NPaBlcV2Y32kurXet6+Tcc93g0t58
uQ2rHbrtn+d6sdt8YS50GPtfPJdncPeFvdAe9eNz1E/P0R86F/vFfk16+s29
8KrsIP3Bc3kGd1/YC/ao7Rz194I88UfNxX5Zcgcs7eWZ++iFp/FLPq/gg0ky
giZkvWrWollaWSYkZB0igHchCbVxl8ak70yyyFb9wZ7uRIUNnyn1clLA9dp9
2ULyz5WfVoTbZG9PLgO/lIEqvXCLc7tSUJ49k6Q/sD/m2B3zz52YDYd/Prpi
DlfChGY3iIZJTLvses1lQzixKEfpnB4Glho9oCY0PyBwsGe2Zr++rz6p32yY
2zqbp3Ot2M6+VcyDoh+SPzQNsCUt7qQLjRh09D6+F4VlDEdWaGp2aw7Nq/ir
QIldA2a1d9+9zSWaKoBF+MliVCeSDCtjtdy0epQxe3kB9zeahAHbeEMMh54G
HM6RX8DWbK9L0Rv3M8b6qjvx+ZQkxPkFXBdYG4sZ8Io0YEMzfd9VtEfdWdXl
L/ELKYsKhwHmmGk+xqfmdV1dlnwebNY5sjxYFXVMlcRKkj3v82kpy8d7Ei1Q
SQ4vSS8uCa68iA/nptaIG0aqPNRTVyyIZEBBHCwwQEaRqCvzVt6ZY8UQd69d
EIZasELXvQLMYZfaaxBMXFjU+fIG+ovzx4XkvNBh3McwGodzg2f1LeKHrgBp
dW7A36Lqr+vyQhxIbPoSoudHKvgkTItrfX2JuHguwnEKO5GlzbE6xs1nC9Wb
1IyK6EX3cyQtA2y0ws94OUjco+KWAcdJTKKjxRj940JaEbdRxGTB/V5YeNSM
02Z14dO0v1dy+vu9v8fCX7RB9fzWi89HSGuzYyoFX3nGRT3cHhOwAtlihREX
X3dXsAUr+3u9FQatOeU0Z0ZdRsup9aXNFcOe0vxCi884wLWUD/JZ2D5bdwLd
bT3kM5L8Gt6zTJpHC5AWCPF0MSWeQrb6PptPiHqtWSKZafUQBwpxvLmmAh/P
byftk4n2XmaU3zKd1zTS2va6AlQk2736rLM+QXUcC2lvUAv4Op+OxoXQB5fZ
QbIETff3OCHgrDALGWRkMYypFQ4vC83WJWlKGTpRROpo/LD10WmqHjoWgnOR
16WqbVj6lvuNqcuhkJNx+amQPDbR5ou9roSL/OfylsaETzCPXwIZ8klBpGT8
2ESxAMIEr2XXOKLPtpPJS531erKBUbBrsmRbr2gSFtZsa7FlZ6u9fsAIQHZZ
DGUUCZCHJD+gmEym4STFPvYcjtWuedNoGXsFWVg0LmdAX9l4KVoxPiEM/nLC
sSbusu2AM0JsHvd3U2qKI1cjgGLM1yAzBZe55Nn+9ZAA+/q8MmYUOpBf5d9N
/bePf895N5S6kODZ9cwt8v/thP/chmiKrojJnbyW1CYoOPlrxoWGZLBeb50L
82TamFOu9fixvbPpjbPN9bdxY87Q9UYev0veQc8b3jOYTiXOIUEW3UbY/3PF
rX3Gg+yDHOJV0RT/tKY+j7/88l/H3f31sphddWdFXnf5mx5OKT/SnVyU3cec
ffH1wHFkJp0FuVvsvLi6KrpiWikJuMQJLu5wZzF7RHuImCTNC1kvlgFhXVq+
jFAJbtoInC0VYTV3YEbYRc/1k3HEayMbf8BijlGiK7t5fMuZzzT3HJa0djul
yqJAHcW4D52H0BaOW6dTzsdN74Q2Ei+tqaHdgXWgoAsqxwUg6Q6rgrdjC/OQ
KynoJwdGYtudMI7o1F6mfOv5aVBfW5545owfSsmYOi1sFcLMeCGIXDg/7Zow
8qLQMKKKbux6fqHkJqHuKHtDMySOgJYtTCq6msCSL8jHc0C0b3lVenzVV3ir
W+d33XL0lRCzq5Ahg0O33my8Z6cEHPtmKYsAecnTZvXgWwG+KrTx4gGxcUZb
RVgQ7tbeFFy0jAttxLnDW6Ga8guD//hREWz0hGngAFdrtL3xqVOWllZxNR9b
HzhhzA+2xdOzUUNSC8jllTpAs5zot6Ws9YaZ/3hVYktgatNgMzXhg9tzaC7y
6vHB+WH2887pUbafz1iUk6g7TFSi94YkJwGf9y34W2tGbn6jwaLPdrP5VDdv
thBdemmSiG48MfP5SDmbL6OQerSJKNbzO3PFTlnwgGwtlHKRGROqGvNYglfB
prKAobr/XqZTkFnEZcTpylErYaNSoWxaEqeSIbKUxR6OZk5TUYyrh66JfT6R
iFVXp6GKVQBRfFbg+DgIDKy3iNjax2o0CDPscSRpGh/bSR8ih4rErul0Rday
mGDJaGghtf0NjmTNIwd3VUA0OJ31xE4FkkM48RtuSo4Z4wwRMeh0G6OYAOOS
1R38ynn7WLhp4LxOJ+CvFnlSlLOBJcYvgljIPoGdlnBACSMOM4TVcVKoUK85
TPL59a2qHOrCg+zs+hcSWCZ6D+PolF8goaMs7uX8oyyIHYWvPJw3AcxXGrM9
v5y1EPIQs9sIyoUvX7A9e84NJdZP25+hJ4pugWDpri9v6IvbhYlOKK0ubp8N
LPyA2AtXhmgeFpX4Pb8NB2TaKUtN4nVOlwDNge9BN2AmFz5zCDxFGm+oc91k
6PQ5x875wb/75eQTkaCYeDoiKzdlAAbvWyQ7lQpNOkLW286GyDoC7OYA0cOQ
YmR1ODhck+Bja9LMQuLVwC5pLTFvd3w0UNWJeUUKchHoWbepocCpQCaGdiVN
yD7SafSl5dwY0MySKFaCgHi9PTCKNF3ghTOamhPjym24rMiw0jlESDuiyDEp
jjNaqHqknLBEaJ1IBKxo13gyyt2EakAGWvQJHZRmpfB0DopfsZx1Pc/pyMyK
wnhOV664Tbi2cCK+haF9GHO+Ixofl3Zh6TnuSuEFQlGoMAzB1KN+WO2WKH3i
SF7a0WlVu/Kl5UicsYJVY2Gs6CEtkSnHRNPbGrW4L/kuX+BYOlECDdM7kFyL
62XK3LLkNyKyV95B9SMuG2yRd8YrFQFCjiZPx5u4TIBj7YpmIWJbhZrIvmHe
k3xcXfNFWrlWXpJkgBCwj4Me2QvQQIjw4E2i0u0K53zWvstx6WreJ8FU32wm
KDZn22vkgrAtRrKwyUjWPNLdsg1fzDaHJzuRNlf5v7BinulTSSz0pDfybkDt
1XjLKStolh6aruyy6VJlU4WWtb3tJRzo5IsaVAjJOeO/K5tz3g0gP6YRVcFs
FGQkGKWj6FH9kTPC2GllKCD3AtISo2Y9cQZM3tUb5X4+nrAev/CUBY720NJe
q7igaEzoShKqeLu8rqKcfcLIRWx6rYYQpqeTKJFYpEy5KDiBGBJVgFyG+8FU
+n1VKMldRndCJ3Zw1zpeIzDMbFMwmbBWws5nnA60Xg4GlM1t3C4DzojDprXD
8jO9HruFBZIhN4W+KGasp9PCSKadJDmM2u8wyPIkA8QbPGYr3Gqlkz1ARw+T
iepf5Y6ZIYcN8x75RA49H47yVmAoOrfAHFa3t/MJmwihCpDtzLwyXJvGVg/5
aF742UVCGz5cU3BWYF1ztxK45QsCsl+FeG0lXtuKcfzIJ6XlOFXSSkJCIxVA
N/KWmhSE7zVyyK1yWrYR0m0bYyAyo1W95R2Ico3QYjnbiCK3TCq+O3S6SZJz
ZbFb9YWMmZzngkHqqXvYnAhmWFkgX8jqtFi75PQUoo8BOmZ65i/DmdfASkt4
IUhk1i6/jBm+cuVMp6zX8vwqpueHiNRRubMxBFt5IBZD6paLFOMVDUmKyQ7m
wTmFWsQq0RUFZkIMDy38REwRvccgocf9MeVo4U8iLgldPqsItjSIL6KotVNS
hneQWFu3vmndMbVSotyG5fzvQdFQB6Wj+8h50vxUa3elAdsyJ9hKVO+x8vOK
XqxsWGXepKkWWphmamIxPf2magDN4pJq86E5clOaFIh+s9ju56jdI7WDjv5H
nRHGUeJj6QcJ+ih/rCY1U66IbHupBOeJxSyw4DGhirhBH2MBrpM2t9qOyKLI
8RleVQuYmPpmYpRTngtm843199nRxV3dBmAlGcuomaAiLxjltwFRJPMLxtKl
tKbNXsa/0V7yZOjX3qbNTN0bbolQay1lplcjKShLuBfqeMvZ+0NtEGIwYFOC
DLalhoLYBrEhj/UdwNzMCo3Gfe5rix/3mzaIt+s9axxsEI9fZoP42WwQxw0z
Dwtq++qL+yABf1ckAYDTEaUJtpnl2Cu9dUoIyoyc56rqFJxC+iVL1GepfIhA
GVY3Nr79iEBEbJd2WPvE/jnDwTK0bRIhPmOSqBUYzCfH9KSMTNMp2IiRqOtE
USfwyS9q85CGONHICNuJrSBtWJ2POUMf+xUR/YN5Qszc15XQ6BV4zK50Ghds
dK3X0UlIRECrV85iPg8tvXunrj9O1eVBhbwMIu3gsF5eCJEnwCGieBMisK9W
+YjkjzFkUhOUdDHiGwDX1aeBtbX+5rfAyq6l3/T67oq41rifAm72T49y+0/d
DiBaD3cyB9/iZbEjJkgYWrz0kAf2ZCz3rkzEVMecilW92TXVxqdJ9eA8azkL
J1L7XX6ohDvzq2ksCRObNvQ4R0o+ETcc0GCzY2iaFN13Z+ykonMrZmBlWBhg
is2NvcEEzqnBUo03CSxZSaIzSOBhlnO8ANAEuNB3h42Y5ZaARphsTTVqm78b
485rw4JEXddvCGTw+mmVxsTZMIiK2WbH+0hls1Qca+G4xQ3ixUz3Uo6bMejl
TPcyjtuY8Rcz3a0ct8nNL2S6l3HcQTvxQqb7aZbbzC/Pcd1mlIFsqpvggjdW
5Tttmh3/AQl80Atwl9WtDWE7RVMDiKHGsdjTOhDsiEGX1edQuY04d6fkwnbI
3cPupcouczQoJ1ckpU+CmT54fEYmILVdgFiBqrEaUUwNamqvzJgzKkmuLC+4
mLqhtCRcnRNMfV1sQ2eyMuPs+m5txelX2xCJw1DOzKaP3dGUTTnoA2aQy0gr
w5hzX5WjXNgUUyJb4s+opoFAqQGOyF+L050KyIhWifWI1dpSKAsSAewZ9U01
HjUvqA6THlVCgh/iihQ6YtSxDQ4Tjsj+Yz4qBAS2KnHcGvg09AMApgRBsmDO
5pMiIAJ7WE4K0XNM7Ue3BaEjXkW46NmMykCTv1kDL8qtOF9qHec4RZb99CQN
1drzZr1PTCtNIjFqZKknKhSldWn6OpooO6OK5VKC+oJ/NH2FoHEJW615WSd3
hlALJQtI2qs0sKF8zlVtGZDFjMiwBBQ4JUZ72PWUulJlo/rKIrdw4emJm6Y3
wM8LzWJ1155lN3fVZgo00QbT2cHNjsS1nM6XdyZWQtnmEJQ4y5UQuG5MMOtI
bWZGCAZLOFWcPz/WvaKv73c+BLLl6nF1JcNNP8mV8VNq5znRPBKPKP+jzzY3
azF1HLnEr4oacYstiGt8Cytv5GlDVY9myvFa8hVbLmuPH6qtYh1Artgj6cwK
HnOW15+Yaco5hCDRNb8SUYqdEFldDYTg9tjDy8q0Xit0xY1XVJb2BWsWeZiS
tSOzY/FFCrUmv8CGdiIDc5odzVVy3YcMd9F9qflnmywXvP2kq7AgmSB7mGO4
5Wm/+dMFCeH9DQEVnkla6nuw94DQtARGnZd1YqEDTEwji6P1idS+XzAS50yp
JX6h4HPMHZR1pQ4ybelTRD4RBYWbtbxYQhqxbW4pqXpYLPwLcxAiQZtR5lGk
LGpYS5RK2nWATn6dQ+fCc39tc/OY0ZYZ+P7L8Xi3+Q5adjdAIjbiHq8VD3zP
esEMnFp5cVZV44DLri/uuncGNzAaBZeAQHlwWxWfZ9pTCLxmPEbVhujQKcFn
60WjmS00v8vZJw3+eotntKbL+xLaZYIgzhmjdtBvQy1nU74q8pmbCeXGyEej
qVK3cipM/PoiZQDX/5CLJoEIF0Z2/xjRgqnAoFOGxuJSiN204NSNOrTHE8wv
lJxFMelZ5prP5Ni2IjnPSbecRq9n0aDamQ7twQTifTxWPpdXpS1VBLJyF56d
Hxc5jCyCCMG+GDnVAFXYegZlpgeVa1Lpzfdb0CTqX+96b/AXLU1dX/pv39oV
vgBuRQkenZVAj5P8Vm9NOAA5TVU4Nm1/Ki2yPqbQTRsZzWX1olm0h5izdu9d
Pwa0MyBBgUV/sq1oxrfarAjhIBOaK8E4n126l4CI13TGtINF246yda8jbxXh
3iyqXPm6FEkSFYvplm3wwhKyz1iN2RFnEy5ckuWhuleWRUeJjcsSBhaL7E0s
9O0X1BsbYOZ3lWXrP/2Q+vioHIEM/Imvj2jxBBwicM/FAxnzkg1l58HX7PsX
XQ8mTmglmXZiLAFYynzw+pXYh4yq2clnGO4taEVkwvbetC/O8+kbKFzvCrFW
tGldJcHdcrSS5TOVS8CbGOv6br3vjCtDZs3R/oNhOB1XrkiTpZQh8a0wSzqu
Pr5VdHJ2uTHOXE8Lr3Fkl0OoXsNgvKkmFXuonWuwUz6JxDXQqOHJ98QWTspZ
NbWKTcRNKhyV1ATn0mYCfr95vum/e7voda5LZQ+NryBTdB/4yI/zR3s9+TF4
MBDzNrtcz3Yrce9GxS3R2+e8utd3qKx8b3umQiofLALdTTUy0vTuHXviMTsK
WYaOCGuKTRK05tqRFtlgB9XBvL4xCrb1htnOaHm2rwvbisLSn6XkmIUOtu0s
K7B4L3GRSYUIaNz0tlfMTk7mF/o1yizqgGgYRLkfcLYcUEuwnTDCwGvHfflE
QWjPILsSN3rH/P+QSLPSy+wYHI6m91D3vfoy74KhL7VClmk77ER6CBSt9fzU
ZILVuihUlaIvaPW9XOUgYt+qUsUIw3R1t1KioXb13GUGamsVS9gsZgn6UquW
TKBjRjr8orSFLzAwbOOkPFTCpbBSfl6CSE2KuFpImJxS30s6dKB9jyE02K88
lisFKrfl9dSqcCFE6bps4RIS+kyinFThIBanugNZ6UHZ1HPIl1fqPyzaGV97
9ndCNcCLeMPGpcpEMrWeicRVqWlW3nJnJpAX2oJkXhxPHERzDSRJp8Y80vU1
4sqw5td1hFtGczD/mgbK1bdUDIdG9syJvfbDRkg6mM/M2YaVTwQZ2l0sxPQ9
8LwP51bqRTRgsCqxTS6AjwAuU2OltxB6abytK1xT7rN1hwVHpKwGn5W4CJtE
NyzI+hbvSX8T6SjVYJzALVQMWqyxJh72gJi47Dv/zAWG5ACyAx1NRSrd4QbL
zrjeZa38wBUQ/CpR8VeR9qbnN+Cb/tZb4Q2ip+uwemqDrS3kwzZWOVqE3HkG
7ShYPpZR+GikzKTskihx44zeoiqYzdSSxU7yONjxmHHxKRC6453THZSLDTVp
osRYvg9eJfMWGdPBHfJ7Sk6k4iCtfc75RJu9RWDZwAL/jfVdb/pJKZXrYlJA
/1xbL0mdnIhl4kiUSxOXGjJWx6pUcWE/swmFym5pp9uvXu1FIjFLX9HoCqbt
V9u0OBO6vIX5O4TUU4CP2Q2D1l2KrrXWowL/b0HUlr9VK9nqtiaePkxb2gox
/vLLM2Uc6ZYR+EE9prCUcWnrONJtDh+Tmd5yWPGgAD6Hreq40lqSBvg8dAfq
WFmFalnidmCiPrGR+eUntRLBzW2EkCu4ePHwGn0mdhTE2jK6orwNNYNBJS0m
J/5z5+xmQ9iuYewRO8ydqtChhCEo4mpn3MBe+U3LdL2WQozBmyXgjjMYzDYR
ZOfjWNMjN7iDgC4Wiaq+L3N+w5xHI9nIipA5Cr06PTjf+/70MDM1IPgxXsjZ
wTB+8n4D9Y2M332m+2y1t6a5MapXXOZWsDiOfmY/OOMLh8M/6zhvNt9uYu/P
T4Ye4PFmSysrvfrh4/GeMcYbGxvmQ7S66cOxPeJ2zlJfimPrhGPsGqErFnh5
0VahZ4KA7/sMBlf3MN0L9xoMJ5cz60AqHvpRs+7pVwchzcnqkt4Ro6ziJ5v0
TY3B5VVdjdTWiReECxhp3OSMMxVsL94nLOkpSXVVkVx9jLFJedKgeki54Und
DeYTP+B0jp1ERdpArTyIA73j3MFChVyOGS2bRkqPem03Bj5TULcTCeQRiC2C
GlXGl+Wsk0AenpluKiizE+BUmWhVKadSrlh6TOM+YeTRIATapfltqqpVh1A4
Sk2kgLLIK6a7gvUZoaWdaDIcXx48Y8UKoBQbGFM7/ielBZnkyESh4LBSHnRA
mbDjgJB4+g/2iZ9h8sAc9sFV31m79S7KySi5FzI6yCOUfhOvO4I0B27G94eI
msTmGA83KoSts6le3hSXn8w64QkddNF3U5KdxsU1m0zM459Wx44VSCYuwV2L
28U2PJxJEQ659qA9UwUO4S6iJME3XEkgbS7sES0SnlvXlqWcoMSBlQkXyri9
gKHGcbxdByvWS9kONUKaxtkKZkpwXO468BPaqXF2wB50Wq1veHKwZoLYZMS6
s4J49ce7QNIWg8yiipL/T/e61jCmS07qZnZ1UpZGB3WFIwufmTBV3BHGNEFg
1chIppJMjsrrOAfG8eCV6ppVkJLj8lXY3GH3dDjcOeZaRUwv7ro31RUXDrSQ
srjO5APb44QHnjL91Q4I2Wf1K9Z6kmg70jQMQIXB/ZYrvLWA4CSYEL1rrh0r
/AfsJWBAHkLql4UEIK8ebiqWIwMyx4x26hAmoumV6W7d0UGiGDSdaq6Z8NfZ
EQr8O/KcssVRmX0sUd/B8zGCfXGIZiqNi82aa06DncjZXYAkt1nC/xbm8DSv
rYtXxtzQC9O5YGkU3O7VPl8MHVvxGFcuq5pG+S1xHMY6CB0aSyV3qwAA7eBw
CV8fGWDEz7JZP9QUEIGdQQnWFlmRmbC4WBRviXavij6/fGmUaLS4Iuw6XCEC
BwFimsf2VL/J2QLqyzqc5reFePsR/pq81h0YU0lT+ms5ZUZoQLSUS68a57w6
GEAtvLZiXFev1zMqtbKj8o5cZ0No0MTrm4bZPRq8/jAg3ux48ETv2nekv91K
Zdc195Sj4Sb5+BHJZ3QffIH09xcNp0vpv++57Atb4bQgJhA6zcXKlstEv6iW
+aI0H/QXKX8pGkqnzWmJ9rlc9McD1Bi2KmbiRcCuuVhQdArSfLZyi7OAw6wk
X3Edu9jVgFLSfX9dzspbVizFzn3s3SnyRKyy9+tZcmRM23jHsIHfpH4jCt/f
AtHzg8iiRue02+1mF3RsIdKneQJPWJfAVHdHqC5WgWTcPLxdyofuzCCq0vut
bvFZ/Kr3PQg/od1qMFanJItvDoKXeNay54vdFiGhxEhFfjB5xrmGDiXNnjj5
h7CAXq+tGoh9Tg+DVdg/4pNYjLzpKse3i1FCW6+JXQ3WBrm60Pg/2hJG2uc/
w9P/RGPJePmC/6Dxr5/ps730P7PZaLQ9os+vX9xzy5x7m+/5lkqnL2b52YwX
3iW58RyRJmi3xk9G/MGTfZIK3+iTRnbKXq89L6Xd/wfh2hdWKUbBpwsoEiXn
w1OoeifBAKGvnNmCfZBwSxBqfrMl17HSvxhTX6n5dc7mYc9jciiJoDTngfqN
TjSyJ+BSko0Aoq8tsJGbJGZz0D9d5RLZGM+yv8mzlI6+2erSH3xpuROGni09
KJ4BfMF/qKHjrNyrL1FS+XlSCyhSqGnKGxXn6YQsUClivNedUG2whWqBUFnC
m2JSXCnYbbLG0elSwAET+NlXhqt5mwlD7BM+3ZCLXaqFg0mJ1u800aTeLHbT
auTlh7hd52U3uHzRGsRhOwSICF1PcEtsureiRJyZ97H6koXOOsr2cmdSBNKR
IkEE6i5GxKK27DXs+3kIMbWRkZVvsxWiZTsrws2a9kquO7/oOKuOuD0zHVXc
Dr5VdNf7qOIpZ+49vOzNjY3e9uji/Xa+vbG9/fqbLfPKwNi7KwKsJwZn39lo
/PaBl456oaOqGsB2hFMDsrPdg9ZhqLezFb/Hd7Liwy5NbpUoVnej1yH61N2g
T08UWKHhbvZBLLAsiE4nmuGFGINr4j0+HFfna9ZL33vpr3l4wOKQUVycAiNd
51TMN4Rx8N0dmeNl0uiXCOjbvY2NbVpBBBH56Z9sehb8+mV7A79hhf8MyS6k
Z05fBjBVl7MCFCVZPa3QHPx4mX3u1Rdqa/AjsXyefZpAP50n/yT6zdrdI+n1
GhPuy4TxfMlET4hHwnn6RzGtQmaEaaFxk4GChsD0xiHKxUSsDj3fvN00vsAZ
g3gFhGbZKk7UWtb6iZdmbXfXnkiy/gWfdCa8wa9xJz8xhdBIZrA8Dfwzn191
BgudfE03e/o/pMgGnjOyfNtbe0EnS/PVt8xXO2FO5d6zi3/NvMvXIXU+l4D2
Ck2Ssjs0vhc+pzHKr80xox/um4/TGgfVt9HnT982Pgs/hE9lnZweZnHpJpSE
S2YyiCs7nWy+Pul/vS4fLIve/t1m8jvAhCf6t4XdcQEh2p2/Le7O35wL/dfx
ZPFxG8aCxgm+9tde1MmXfKyTBUrYcnoXSGN0eP+1z6us0orj2SoLvZ3s6HzQ
/ahC5yIzEL/KOekXcsovckbGxe+HX4yb55u9nZ+PmfniKXaexNHLaTV5vBV+
b+fiAgEB7pVTfJ51c/pNGP/+0WCwjS/bWX86yo5gXJblDWgA+qO+Ke9AMOBG
xm+8PdrTF94eZXsIj+NffzgOvyKz7PGEU/BXU8lFs7mjj3ck+In+kQfW2Q40
azcMjL1yejkvZbS9A32+Z3ftwehahtw7PrNn1e1tOcM9dhxJCGdI6csNh80+
hqU9OvUupq6akSeVv8U5ciFnqV8gPx74i2KAgXivjz7aowJpSMdsp/g4sQV9
7IZ3Gw1aO+t+XNr8I5Qqoe2+wVKMBIwQ8mDfF7MfhU/tFxOUKg0rE4eG/aFP
cD91dnYHl71qVGQD4D+/UewNzmz7i8mNRN7uSf3RwfyCmCLajFFZCW+IXKr8
2uHxrr4UJSGLd3A3r6Xl0eDMFnCk7g8D0fJKv/HOXJ9ar9enNM1d6eDcloSu
9IizVka1mdaq+/HpdgLzO4f58ZF1zGsriZU9IljBgzHpmj1ttOUJm5A3l2kG
pX2/2b7/dPvhwFtfEPUaSnWvEceOcgtQb22ynFWXloMTgzaXvHALbtw1/PRF
ptKmTbWWPB02nkrYDD86GzSenampkUlPGfWx19aJHZaxIvnAKIVzN04pBk4p
BkX+qZ1I/OBH5Id5bgbRGK/Odmw/BOd2xOoRb8KZI/SZere0YjOi7qydLTkK
5U0RZ7ivTWXR8YlU2kqXjjXxVKm3+VT1EOGUDk92Gu3EbrcDv2HOqiGtvm9t
9b05EksruaKspUQLN72ox6rd2KkRZcSeQxE8pJ/heby81zbm+eOdDnTms5FM
lgpZfXi/1f44g9MMK/DFR8swyNJaME2XRweNRwfBuVManIYGauKJ9/yjvc+E
4eC/5+Wdw9Ipd4NQfxwcLjxIz83Hs5MTm/PHMVF9QpBxyQbHk+qBDqIE6u15
Hit78a8njqZGLkQdvTMt8mTigb48RVf+enbYaGUQBm8R6LY0/mlx9IPPM5gx
ZOaLEwGzgsDWcTG6lmKTv2yLa24x+nblKh/XxYolAGWB/wZuAOJFyZnRJHZ0
8olYo2mZT7LDHG7/ney7ipD2z/mYxNZJJzsnoZfDKIY5wpmPpsV19qGc1p8e
O9nZ//7PqLymfTgqyotOdlpefhojfHJ/PftQTadl3XEebz+flITWdLdewoF3
PC472W6V/TjvZD/N6SgTWOh+uhYr0X5xUU3zm2x3Op+gUAKUbJiChByBJ5Mo
rKRwB7955UkjGZWtxgoccEOQF3uxINoYq2dby3clHf1KtyYBhwd2S0VF6DQm
7oOsU/Fwc+tuZ3yfTytCPDq6Ob/wAQD/cLk7hSevdTmdXXdHviAC1s8V8YxX
89uSQEnfRnm08GxW33dzTnSL1rQx5W01u3nMfiwll4f1imI3odcOYTw9PLim
bfKiMPCEjLrCCN9VdXFHDHQ+rh6KR29IfHzcF5ZC49KYl+Wk/lSGPAB3dWjX
BMd39MbRvETc4Mjf2Nlf0vpgWn7K/gI38E72F0CQUHCczwllYSlV9KDzW42j
eR4fDI+8v/8D8YJMOfcxAgA=
<!-- [rfced] Abbreviations. (To view the updates to this section,
which was moved to Section 2.2, we suggest using the alternative
diff file: https://www.rfc-editor.org/authors/rfc9889-alt-diff.html)
a) FYI, we updated the expansion of GPRS to use "General" rather
than "Generic".
Original:
Generic Packet Radio Service
Updated:
General Packet Radio Service
b) FYI, this entry appeared in the original, but it was not used
elsewhere in the document, so it has been removed.
UE: User Equipment
c) The abbreviation "DM" appears in Figure 7 but not elsewhere in the
document. Will readers know this abbreviation (perhaps "data model")? May we
add the expansion to the list of abbreviations in Section 2.2?
d) "AMF" appears in Figure 8 but not elsewhere in the document. How should this
be expanded?
e) Will readers understand "LxVPN"? It only appears once in the document. May
we update for clarity as follows?
Original:
The correlation between an LxVPN instance
and a Network Slice Service is maintained using "parent-service-
id" attribute (Section 7.3 of [RFC9182]).
Perhaps:
The correlation between an L3VPN/L2VPN instance
and a Network Slice Service is maintained using "parent-service-
id" attribute (Section 7.3 of [RFC9182]).
f) FYI, we have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
MACsec: Media Access Control Security
MNO: Mobile Network Operator
-->
<!-- [rfced] Terminology
a) "DC1" and "DC2" (no space) are used in the text in Section 7, but "DC 1" and
"DC 2" (with space) are used in Figure 30 and Tables 1 and 2. Should these be
consistent? If so, let us know which form is preferred.
b) Please review the names of domains and let us know if any updates are needed
for consistency. Some examples:
Provider Orchestration Domain (Figure 3)
provider orchestration domain
Provider Network Orchestration domain
Customer Orchestration Domain (Figure 3)
Customer Site Orchestration domain
3GPP orchestration domain
3GPP domains Orchestration (Figure 6)
provider and customer TN domains
customer and provider orchestration domains
c) We note capitalization inconsistencies in the terms below throughout the
text. Should these be uniform? If so, please let us know which form is
preferred.
transport network
Transport Network
mobile network
Mobile Network
d) We see a few instances of "5Q QoS". Should these be updated to "5G QoS"?
e) Should "Slice Services" (uppercase) in these sentences be updated to "slice
services" (lowercase)? It seems that "slice service" is lowercase in general
text and capitalized in the terms "Network Slice Service" and "5G Slice
Service".
Original:
The objective of Transport Network Slicing is to isolate, guarantee,
or prioritize Transport Network resources for Slice Services.
...
Putting in place adequate automation means to realize Network Slices
(including the adjustment of Slice Services to Network Slices
mapping) would ease slice migration operations.
f) Should "slice" be lowercase or uppercase in these contexts?
Transport Network Slice
TN slice
5G Network Slice
5G slice
g) In general text, we see both "Network Slice" (uppercase) and "network
slice" (lowercase). We suggest using the lowercase form when used on its own
(the capitalized form is used consistently in the terms "RFC 9543 Network
Slice", "Network Slice Service", and "5G Network Slice"). This seems to follow
the usage in RFC 9543. Let us know your thoughts. Some examples are below.
Examples of uppercase "Network Slice":
A TN slice might be considered as a variant of horizontal composition
of Network Slices mentioned in Appendix A.6 of [RFC9543].
...
The use of VPNs for realizing Network Slices is briefly described
in Appendix A.4 of [RFC9543].
Examples of lowercase "network slice":
The document is not
intended to be a BCP and does not claim to specify mandatory
mechanisms to realize network slices.
...
* Providers may want to enable differentiated failure detect and
repair features for a subset of network slices.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
<!-- [rfced] We made the following changes regarding the <aside> element.
The <aside> element is defined as "a container for content that is
semantically less important or tangential to the content that surrounds
it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
a) We placed the following note in Section 5.2.2 in the <aside>
element.
Original:
Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, queue,
etc.) are provided for illustration purposes only and should not
be considered as deployment guidance.
Updated:
| Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP,
| queue, etc.) are provided for illustration purposes only and
| should not be considered as deployment guidance.
b) The following text in Section 3.3.5 appears in the <aside> element. We
added "Note:".
Original:
| In order to keep the figures simple, only one AC and single-
| homed CEs are represented. Also, the underlying bearers are
| not represented in most of the figures. However, this document
| does not exclude the instantiation of multiple ACs between a CE
| and a PE nor the presence of CEs that are attached to more than
| one PE.
Updated:
| Note: In order to keep the figures simple, only one AC and single-
| homed CEs are represented. Also, the underlying bearers are
| not represented in most of the figures. However, this document
| does not exclude the instantiation of multiple ACs between a CE
| and a PE nor the presence of CEs that are attached to more than
| one PE.
-->
<!-- [rfced] Please review all the SVG figures in the HTML/PDF outputs to
ensure that they convey the same information as the ascii-art in the
TXT output. We have included some notes below about particular figures.
If changes are needed, please either update the SVG in the XML file directly
or provide updated SVG for the affected figure(s).
a) Note that "===" appears as a solid double line in the SVG in the HTML
and PDF outputs. Are any updates needed for this sentence in Section 3.3.5?
Original:
For example,
the bearer is illustrated with "===" in Figures 4 and 5.
b) Figure 4: Do the boxes labeled "SW" and "PE" appear correctly in the SVG?
c) Figure 5: Do the boxes labeled "CE", "Mngd CE", and "DC GW" appear correctly
in the SVG?
d) Figures 12, 15, and 16:
- In the SVG, the lines do not extend all the way to the boxes labeled "PE".
- The "+" signs that appear in the ascii-art do not appear in the
SVG. Note that Figure 12 has a legend that includes "+", but "+" does not
appear in the SVG.
- Figure 12: Please consider changing each asterisk to a different character
and running aasvg again to get new SVG. It seems "+*" together does not appear
as you intended in the SVG. Please see issue #20 for aasvg
(https://github.com/martinthomson/aasvg/issues/20) where using a Unicode
character is a suggested workaround.
e) Figure 23:
- The boxes in the SVG that contain "5QI=", "DSCP=", and "TN QoS Class" are
not closed in the SVG. Will these be confusing for readers?
- In the "NF-A" box, a pipe character is spaced over. We can fix it in the
ascii-art, but we are unable to fix it in the SVG.
f) Figures 24 and 25:
- Do the boxes for Slice 1, Slice 2, and Slice 3 look okay in the SVG? They
are missing some corners.
- Do the boxes under "Slice Policer" in Figure 25 look as expected in the SVG?
g) Figure 26:
- The bottom right of the figure looks off, i.e., "/|\" in the txt
output. Should it be moved over one space to the left? We can fix this in the
ascii-art if needed, but we are unable to fix the SVG.
- The "..." in the txt output does not seem to be reflected in the SVG
output. There is a solid line with ".." in the SVG.
h) Figure 27: Does the ">>" in the ascii-art appear as expected in the SVG?
i) Figure 30: The filled-in dot in the SVG overlaps letters in the PE boxes.
This should be updated. Please see the note above regarding Figure 12 for
more information, assuming this SVG was created using aasvg.
j) Figure 32:
- Does the arrow "v" above the "^" above "MIot (SST=3)" look as expected in
the SVG?
- Do the PE and NF boxes look okay in the SVG?
--> -->
</rfc> </rfc>
 End of changes. 304 change blocks. 
3445 lines changed or deleted 2151 lines changed or added

This html diff was produced by rfcdiff 1.48.