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
	-ietf-teas-5g-ns-ip-mpls-18" category="info" consensus="true" submissionType="IE
	TF" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.28.1 -->
	<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.
	<organization>Juniper Networks</organization>		" role="editor">
			<organization>HPE</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
	<organization>Juniper Networks</organization>		or">
			<organization>Nokia</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>richard.roberts@nokia.com</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?>
	<t>Network slicing is a feature that was introduced by the 3rd Generation Partne		<abstract>
	rship Project (3GPP) in mobile networks. Realization of 5G slicing implies requi		<t>Network slicing is a feature that was introduced by the 3rd Generation Partne
	rements for all mobile domains, including the Radio Access Network (RAN), Core N		rship Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requi
	etwork (CN), and Transport Network (TN).</t>		rements for all mobile domains, including the Radio Access Network (RAN), Core N
	<t>This document describes a Network Slice realization model for IP/MPLS n		etwork (CN), and Transport Network (TN).</t>
	etworks with a focus on the Transport Network fulfilling 5G slicing connectivity		<t>This document describes a network slice realization model for IP/MPLS n
	service objectives. The realization model reuses many building blocks currently		etworks with a focus on the Transport Network fulfilling the service objectives
	commonly used in service provider networks.</t>		for 5G slicing connectivity. The realization model reuses many building blocks c
			ommonly used in service provider networks at the current time.</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		<t>This document focuses on network slicing for 5G networks, covering the
	connectivity between Network Functions (NFs) across multiple domains such as edg		connectivity between Network Functions (NFs) across multiple domains such as edg
	e clouds, data centers, and the Wide Area Network (WAN). The document describes		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		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)		ing existing IP/MPLS technologies (at the time of publication of this document)
	to optimally control connectivity Service Level Agreements (SLAs) offered for 5G		to optimally control connectivity Service Level Agreements (SLAs) offered for 5G
	slices. To that aim, this document describes the scope of the Transport Network		Network Slices. To that aim, this document describes the scope of the Transport
	in 5G architectures (<xref target="sec-scope"/>), disambiguates 5G Network Slic		Network in 5G architectures (<xref target="sec-scope"/>), disambiguates 5G Netw
	ing versus Transport Network Slicing (<xref target="sec-5gtn"/>), draws the peri		ork Slicing versus Transport Network Slicing (<xref target="sec-5gtn"/>), draws
	meter of the various orchestration domains to realize slices (<xref target="sec-		the perimeter of the various orchestration domains to realize slices (<xref targ
	orch"/>), and identifies the required coordination between these orchestration d		et="sec-orch"/>), and identifies the required coordination between these orchest
	omains for adequate setup of Attachment Circuits (ACs) (<xref target="sec-tn-nsi		ration domains for adequate setup of Attachment Circuits (ACs) (<xref target="se
	"/>).</t>		c-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 196 ¶
	| | +-+--+ +-+--+ | |		| | +-+--+ +-+--+ | |
	| +---+ +--+-+ 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
	<t>The realization approach described in this document is typically trigge		ref target="RFC9543"/>.</t>
	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>The realization approach described in this document is typically trigge
	t, is out of scope. Mapping considerations between 3GPP and IETF Network Slice S		red by Network Slice Service requests. How a Network Slice Service request is pl
	ervice (e.g., mapping of service parameters) are discussed, e.g., in <xref targe		aced for realization, including how it is derived from a 5G Slice Service reques
	t="I-D.ietf-teas-5g-network-slice-application"/>.</t>		t, is out of scope. Mapping considerations between 3GPP and RFC 9543 Network Sli
			ce Service (e.g., mapping of service parameters) are discussed in documents such
			as <xref target="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		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		he transport domain, 5G domains can expose the 5G Network Slices to the transpor
	domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or		t
	Layer 4). Passing information between customer sites and provider networks is r		domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or
	eferred to as the "hand-off". <xref target="sec-handoff-domains"/> lists a set o		Layer 4). Passing information between customer sites and provider networks is r
	f hand-off methods for slice mapping purposes.</t>		eferred to as the "handoff". <xref target="sec-handoff-domains"/> lists a set of
	<t>Unlike approaches that require new protocol extensions (e.g., <xref tar		handoff methods for slice mapping purposes.</t>
	get="I-D.ietf-teas-ns-ip-mpls"/>), the realization model described in this docum		<t>Unlike approaches that require new protocol extensions (e.g., <xref tar
	ent uses a set of building blocks commonly used in service provider networks (at		get="I-D.ietf-teas-ns-ip-mpls"/>), the realization model described in this docum
	the time of publication of this document). The model uses (1) Layer 2 Virtual P		ent uses a set of building blocks commonly used in service provider networks (at
	rivate Network (L2VPN) <xref target="RFC4664"/> and/or Layer 3 Virtual Private N		the time of publication of this document). The model uses (1) L2VPN <xref targe
	etwork (L3VPN) <xref target="RFC4364"/> service instances for logical separation		t="RFC4664"/> and/or L3VPN <xref target="RFC4364"/> service instances for logica
	, (2) fine-grained resource control at the Provider Edges (PEs), (3) coarse-grai		l separation, (2) fine-grained resource control at the PEs, (3) coarse-grained r
	ned resource control within the provider network, and (4) capacity planning/mana		esource control within the provider network, and (4) capacity planning and manag
	gement. More details are provided in Sections <xref format="counter" target="sec		ement. 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"		counter" target="transport-plane-mapping-models"/>, and <xref format="counter" t
	target="sec-capacity-planning"/>.</t>		arget="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</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 636 ¶
	| | +--+ +--+ | |		| | +--+ +--+ | |
	| | |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 "Transport Network Slice" refers to a slice in the Transpo rt Network domain of the 5G architecture. This section elaborates on how Transpo rt Network Slicing 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 Transport Network Slice
	mechanisms such as Virtual Routing and Forwarding instances (VRFs)		s based upon
			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 Sites 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"/>
	<path d="M 144,184 L 144,240" fill="none" stroke="black"/>		<path d="M 144,184 L 144,240" fill="none" stroke="black"/>
	<path d="M 200,96 L 200,168" fill="none" stroke="black"/>		<path d="M 200,96 L 200,168" fill="none" stroke="black"/>
	skipping to change at line 536 ¶		skipping to change at line 774 ¶
	+----------------+ +---------------------+ +----------------+		+----------------+ +---------------------+ +----------------+
	<-----------------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
	(Layer 3) (<xref target="fig-distribute-ce"/>). Another example of distributed		realization of an interconnection using an L3VPN service based on a
	CE is shown in <xref target="fig-50"/>.</t>		distributed CE composed of a switch (SW) in Layer 2 and a router (RTR)
			in Layer 3, as shown in
			<xref target="fig-distribute-ce"/>. Another example of distributed CE is
			shown in <xref target="fig-50"/>.</t>
	<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 858 ¶
	| | | +------------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 1029 ¶
	| | .-. .-. .-. .-. ============= | | | | |		| | .-. .-. .-. .-. ============= | | | | |
	| | '-' '-' '-' '-' | | +----+ +----+ | |		| | '-' '-' '-' '-' | | +----+ +----+ | |
	| +---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 "=" i
	ibute-ce"/> and <xref format="counter" target="fig-50"/>.</t>		n 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>		<t>An AC is technology specific. Examples of ACs are VLAN ACs configur
	<t>Deployment cases where the AC is also managed by the provider are n		ed on a physical interface (bearer) or Overlay VXLAN EVI ACs configured on an IP
	ot discussed in the document because the setup of such an AC does not require an		underlay (bearer).</t>
	y coordination between the customer and provider orchestration domains.</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		<t>In <xref target="_figure-orch"/>, a 5G End-to-End Network Slice Orchestrator
	es end-to-end. The details of the 5G NSO are out of the scope of this document.		(5G NSO) is responsible for orchestrating 5G Network Slices end-to-end. The deta
	The realization of the 5G Network Slices spans RAN, CN, and TN. As mentioned in		ils of the 5G NSO are out of the scope of this document. The realization of the
	<xref target="sec-scope"/>, the RAN and CN are under the responsibility of the 3		5G Network Slices spans RAN, CN, and TN. As mentioned in <xref target="sec-scope
	GPP Management System, while the TN is not. The orchestration of the TN is split		"/>, the RAN and CN are under the responsibility of the 3GPP management system,
	into two subdomains in conformance with the reference design in <xref target="s		while the TN is not. The orchestration of the TN is split into two subdomains in
	ec-ref-design"/>:</t>		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 (simply referred to as "Pr ovider 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 (simply referred to as "Custo mer 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		<t>A Transport Network Slice relies upon resources that can involve bo
	and customer TN domains. More details are provided in <xref target="sec-tn-nsi"		th the provider and customer TN domains. More details are provided in <xref targ
	/>.</t>		et="sec-tn-nsi"/>.</t>
	<t>A TN slice might be considered as a variant of horizontal compositi		<t>A Transport Network Slice might be considered as a variant of horiz
	on of Network Slices mentioned in Appendix A.6 of <xref target="RFC9543"/>.</t>		ontal composition of network slices mentioned in <xref section="A.6" target="RFC
			9543"/>.</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 1255 ¶
	| 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		<t>The various orchestrations depicted in <xref target="_figure-orch"/>
	, e.g., in Figure 5 of <xref target="I-D.ietf-teas-5g-network-slice-application"		encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned
	/>.</t>		, for instance, in Figure 5 of <xref target="I-D.ietf-teas-5g-network-slice-appl
			ication"/>.</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 1338 ¶
	<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 1371 ¶
	<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 1163 ¶		skipping to change at line 1395 ¶
	+-----------------+ +-----------------+		+-----------------+ +-----------------+
	|----------- 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>There are multiple options for mapping 5G Network Slices to Transport
	:</t>		Network 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 Transport Network
	A single 5G Network Slice can be mapped to multiple TN slices (1 to N). For inst		Slices. For instance, 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 Transport Network Slices for a single 5G Enhanced
	5G Enhanced Mobile Broadband (eMBB) network slice. It is important to note that		Mobile
	this mapping can serve as an interim step to M to N mapping. Further details ab		Broadband (eMBB) network slice. It is important to note that this
	out this scheme are described in <xref target="sec-firstslice"/>.</t>		mapping can serve as an interim step to M-to-N mapping. Further
	</li>		details about this scheme are described in <xref
	<li>		target="sec-firstslice"/>.</dd>
	<t>M to 1:		<dt>M-to-1 mapping:</dt>
	Multiple 5G Network Slices may rely upon the same TN slice. In such a case, th		<dd>Multiple 5G Network Slices may rely upon the same Transport Network S
	e Service Level Agreement (SLA) differentiation of slices		lice. In
	would be entirely controlled at the 5G control plane, for example, with		such a case, the Service Level Agreement (SLA) differentiation of
	appropriate placement strategies: this use case is illustrated in		slices would be entirely controlled at the 5G control plane, for
	<xref target="_figure-6"/>, where a User Plane Function (UPF) for the Ultra Rel		example, with appropriate placement strategies. This use case is
	iable Low Latency Communication (URLLC) slice is		illustrated in <xref target="_figure-6"/>, where a User Plane Function
	instantiated at the edge cloud, close to the gNB Centralized Unit User Plane (C		(UPF) for the Ultra-Reliable Low-Latency Communication (URLLC) slice
	U-UP), to improve		is instantiated at the edge cloud, close to the gNB
	latency and jitter control. The 5G control plane and the UPF		CU-UP, to improve latency and jitter control. The 5G
	for eMBB slice are instantiated in the regional cloud.</t>		control plane and the UPF for the eMBB slice are instantiated in the
	</li>		regional cloud.</dd>
	<li>
	<t>M to N:		<dt>M-to-N mapping:</dt>
	The 5G to TN slice mapping combines both		<dd><t>The mapping of 5G to Transport Network Slice combines both approac
	approaches with a mix of shared and dedicated associations. </t>		hes with a mix
	<t>		of shared and dedicated associations. </t>
	In this scenario, a subset of the TN slices can be intended for sharing by multi		<t>In this scenario, a subset of the Transport Network Slices can be
	ple 5G Network Slices (e.g., the control plane TN slice is shared by multiple 5G		intended for sharing by multiple 5G Network Slices (e.g., the control
	network Slices). </t>		plane Transport Network Slice is shared by multiple 5G Network
	<t>		Slices). </t> <t>In practice, for operational and scaling reasons,
	In practice, for operational and scaling reasons, typically M to N would be used		M-to-N mapping would typically be used, with M much greater than
	, with M &gt;&gt; N.</t>		N.</t>
	</li>		</dd>
	</ul>		</dl>
	<figure anchor="_figure-5">		<figure anchor="_figure-5">
	<name>1 (5G Slice) to N (TN Slice) Mapping</name>		<name>1-to-N Mapping (Single 5G Network Slice to Multiple Transport Ne twork Slices)</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"/>
	<path d="M 112,104 L 112,152" fill="none" stroke="black"/>		<path d="M 112,104 L 112,152" fill="none" stroke="black"/>
	<path d="M 112,168 L 112,240" fill="none" stroke="black"/>		<path d="M 112,168 L 112,240" fill="none" stroke="black"/>
	skipping to change at line 1277 ¶		skipping to change at line 1517 ¶
	| |CU-CP+------+ TN Slice CP +-------+ AMF | |		| |CU-CP+------+ TN Slice CP +-------+ AMF | |
	| +-----+ | +--------------------------------+ | +-----+ |		| +-----+ | +--------------------------------+ | +-----+ |
	+------------|------------------------------------|-------------+		+------------|------------------------------------|-------------+
	| |		| |
	| Transport Network |		| Transport Network |
	+------------------------------------+		+------------------------------------+
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<figure anchor="_figure-6">		<figure anchor="_figure-6">
	<name>N (5G Slice) to 1 (TN Slice) Mapping</name>		<name>M-to-1 Mapping (Multiple 5G Network Slices to Single Transport N etwork Slice)</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="416" width="552" viewBox="0 0 552 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="552" viewBox="0 0 552 416" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
	<path d="M 8,160 L 8,336" fill="none" stroke="black"/>		<path d="M 8,160 L 8,336" fill="none" stroke="black"/>
	<path d="M 24,224 L 24,256" fill="none" stroke="black"/>		<path d="M 24,224 L 24,256" fill="none" stroke="black"/>
	<path d="M 24,288 L 24,320" fill="none" stroke="black"/>		<path d="M 24,288 L 24,320" fill="none" stroke="black"/>
	<path d="M 120,224 L 120,256" fill="none" stroke="black"/>		<path d="M 120,224 L 120,256" fill="none" stroke="black"/>
	<path d="M 120,288 L 120,320" fill="none" stroke="black"/>		<path d="M 120,288 L 120,320" fill="none" stroke="black"/>
	<path d="M 136,160 L 136,232" fill="none" stroke="black"/>		<path d="M 136,160 L 136,232" fill="none" stroke="black"/>
	<path d="M 136,248 L 136,296" fill="none" stroke="black"/>		<path d="M 136,248 L 136,296" fill="none" stroke="black"/>
	<path d="M 136,312 L 136,336" fill="none" stroke="black"/>		<path d="M 136,312 L 136,336" fill="none" stroke="black"/>
	skipping to change at line 1388 ¶		skipping to change at line 1628 ¶
	| | +--------------+		| | +--------------+
	| 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 Network Slice identification in the TN (e.g., the approach in <xref target="sec-ip-hof"/>) may simplify requi red operations to map Transport Network Slices back to 5G Network Slices. Howeve r, such considerations are not detailed in this document because these are under the responsibility of the 3GPP orchestration.</t>
	</section>		</section>
	<section anchor="sec-firstslice">		<section anchor="sec-firstslice">
	<name>First 5G Slice versus Subsequent Slices</name>		<name>First 5G Network 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 Network Slice relies on the deployment of NF-CP and NF-UP functions together
	F-UP functions together with two TN slices for control and user planes (TNS-CP a		with two Transport Network Slices for the control and user planes (TNS-CP and TN
	nd TNS-UP1). Next, in many cases, the deployment of a second slice relies solely		S-UP1). Next, in many cases, the deployment of a second slice relies solely on t
	on the instantiation of a UPF (NF-UP2) together with a dedicated user plane TN		he instantiation of a UPF (NF-UP2) together with a dedicated Transport Network
	slice (TNS-UP2). The control plane of the first 5G slice is also updated to inte		Slice for the user plane (TNS-UP2). The control plane of the first 5G Network Sl
	grate the second slice: the TN slice (TNS-CP) and Network Functions (NF-CP) are		ice is also updated to integrate the second slice; the Transport Network Slice (
	shared.</t>		TNS-CP) and Network Functions (NF-CP) are shared.</t>
	<ul empty="true">		<t>The model described here, in which the control plane is shared among multiple
	<li>		slices, is likely to be common; it is not mandatory, though. Deployment models
	<t>The model described here, in which the control plane is shared am		with a separate control plane for each slice are also possible.</t>
	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>		Network 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"/>
	<path d="M 56,128 L 56,160" fill="none" stroke="black"/>		<path d="M 56,128 L 56,160" fill="none" stroke="black"/>
	<path d="M 56,192 L 56,224" fill="none" stroke="black"/>		<path d="M 56,192 L 56,224" fill="none" stroke="black"/>
	<path d="M 56,416 L 56,448" fill="none" stroke="black"/>		<path d="M 56,416 L 56,448" fill="none" stroke="black"/>
	skipping to change at line 1516 ¶		skipping to change at line 1752 ¶
	<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 1833 ¶
	| +-----+ | +--------------------------+ | +-----+ |		| +-----+ | +--------------------------+ | +-----+ |
	| | | |		| | | |
	| +-----+ | +--------------------------+ | +-----+ |		| +-----+ | +--------------------------+ | +-----+ |
	| |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 1864 ¶
	| |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>
	<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		<t>Transport Network Slice mapping policies can be enforced by an operat
	be reused for handling a new slice service creation request. Providing such a po		or (e.g., provided to a TN Orchestration or 5G NSO) to determine whether existin
	licy is meant to better automate the realization of 5G slices and minimize the r		g Transport Network Slices can be reused for handling a new Slice Service creati
	ealization delay that might be induced by extra cycles to seek for operator vali		on request. Providing such a policy is meant to better automate the realization
	dation.</t>		of 5G Network Slices and minimize the realization delay that might be induced by
			extra cycles to seek for operator validation.</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 Network Slices assumes
	This realization model of transport for 5G slices assumes Layer 3		Layer
	delivery for midhaul and backhaul transport connections, and a		3 delivery for midhaul and backhaul transport connections and a
	Layer 2 or Layer 3 delivery for		Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced
	fronthaul connections. Enhanced Common Public Radio Interface (eCPRI) <xref targ		Common Public Radio Interface (eCPRI) <xref target="ECPRI"/>
	et="ECPRI"/> supports both delivery models. L2VPN/L3VPN service instances might		supports both delivery models. L2VPN/L3VPN service instances might
	be		be used as a basic form of logical slice separation. Furthermore,
	used as a basic form of logical slice separation. Furthermore, using		using service instances results in an additional outer header (as
	service instances results in an additional outer header (as packets		packets are encapsulated/decapsulated at the nodes hosting service
	are encapsulated/decapsulated at the nodes hosting service instances) providing		instances), providing clean discrimination between 5G QoS and TN
	clean discrimination between 5G QoS and TN		QoS, as explained in <xref target="sec-qos-map"/>. </t>
	QoS, as explained in <xref target="sec-qos-map"/>. </t>		<t>Note that a variety of L2VPN mechanisms can be considered for
	<t>		slice realization. A non-comprehensive list is provided below:</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>
	The role of capacity planning/management is to ensure the provider network		<t>The role of capacity planning/management is to ensure the
	capacity can be utilized without causing any bottlenecks. The		provider network capacity can be utilized without causing any
	methods used here can range from careful network planning, to		bottlenecks.
	ensure a more or less equal traffic distribution (i.e., equal cost load		The methods used here can range from careful network planning that
	balancing), to advanced TE techniques, with or		ensures a more or less equal traffic distribution (i.e., equal-cost load
	without bandwidth reservations, to force more consistent load		balancing) to advanced TE techniques, with or without bandwidth
	distribution even in non-ECMP friendly network topologies. See also <xref sectio		reservations, that force more consistent load distribution, even in
	n="8" sectionFormat="of" target="RFC9522"/>.</t>		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 1878 ¶		skipping to change at line 2123 ¶
	<text x="104" y="308">:</text>		<text x="104" y="308">:</text>
	<text x="480" y="308">:</text>		<text x="480" y="308">:</text>
	<text x="292" y="324">'....................................... .......'</text>		<text x="292" y="324">'....................................... .......'</text>
	<text x="68" y="356">SDP,</text>		<text x="68" y="356">SDP,</text>
	<text x="108" y="356">with</text>		<text x="108" y="356">with</text>
	<text x="180" y="356">fine-grained</text>		<text x="180" y="356">fine-grained</text>
	<text x="248" y="356">QoS</text>		<text x="248" y="356">QoS</text>
	<text x="308" y="356">(dedicated</text>		<text x="308" y="356">(dedicated</text>
	<text x="392" y="356">resources</text>		<text x="392" y="356">resources</text>
	<text x="448" y="356">per</text>		<text x="448" y="356">per</text>
	<text x="496" y="356">Network</text>		<text x="496" y="356">network</text>
	<text x="556" y="356">Slice)</text>		<text x="556" y="356">slice)</text>
	<text x="108" y="372">Coarse-grained</text>		<text x="108" y="372">Coarse-grained</text>
	<text x="188" y="372">QoS,</text>		<text x="188" y="372">QoS,</text>
	<text x="228" y="372">with</text>		<text x="228" y="372">with</text>
	<text x="288" y="372">resources</text>		<text x="288" y="372">resources</text>
	<text x="356" y="372">shared</text>		<text x="356" y="372">shared</text>
	<text x="396" y="372">by</text>		<text x="396" y="372">by</text>
	<text x="424" y="372">all</text>		<text x="424" y="372">all</text>
	<text x="472" y="372">Network</text>		<text x="472" y="372">network</text>
	<text x="532" y="372">Slices</text>		<text x="532" y="372">slices</text>
	<text x="32" y="388">...</text>		<text x="32" y="388">...</text>
	<text x="68" y="388">Base</text>		<text x="68" y="388">Base</text>
	<text x="104" y="388">NRP</text>		<text x="104" y="388">NRP</text>
	<text x="12" y="404">--</text>		<text x="12" y="404">--</text>
	<text x="36" y="404">--</text>		<text x="36" y="404">--</text>
	<text x="80" y="404">Network</text>		<text x="80" y="404">Network</text>
	<text x="136" y="404">Slice</text>		<text x="136" y="404">slice</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	..............................................		..............................................
	: Base NRP :		: Base NRP :
	+-----:----+ +----:-----+		+-----:----+ +----:-----+
	| PE : | | : PE |		| PE : | | : PE |
	-- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |		-- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
	N *<---+ | | +--->*		N *<---+ | | +--->*
	skipping to change at line 1920 ¶		skipping to change at line 2165 ¶
	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
	o Coarse-grained QoS, with resources shared by all Network Slices		slice)
			o Coarse-grained QoS, with resources shared by all network slices
	... Base NRP		... Base NRP
			-- -- 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 Network Slices to the tran sport
	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 Network 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 Network Slice with VLAN Handoff Providing End-to-E nd Connectivity</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200		<artwork type="svg" align="center">
	0/svg" version="1.1" height="288" width="616" viewBox="0 0 616 288" class="diagr		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="288" width="616" v
	am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap		iewBox="0 0 616 288" class="diagram" text-anchor="middle" font-family="monospace
	="round">		" 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>
	<path d="M 16,256 L 16,272" fill="none" stroke="black"/>		<path d="M 64,96 L 64,112" fill="none" stroke="black"></path>
	<path d="M 64,96 L 64,192" fill="none" stroke="black"/>		<path d="M 64,176 L 64,192" fill="none" stroke="black"></path>
	<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>
	<path d="M 128,96 L 128,192" fill="none" stroke="black"/>		<path d="M 120,96 L 120,112" fill="none" stroke="black"></path>
	<path d="M 144,64 L 144,96" fill="none" stroke="black"/>		<path d="M 120,176 L 120,192" fill="none" stroke="black"></path>
	<path d="M 144,192 L 144,224" fill="none" stroke="black"/>		<path d="M 136,64 L 136,96" fill="none" stroke="black"></path>
	<path d="M 176,96 L 176,192" fill="none" stroke="black"/>		<path d="M 144,192 L 144,224" fill="none" stroke="black"></path>
	<path d="M 264,96 L 264,192" fill="none" stroke="black"/>		<path d="M 176,96 L 176,192" fill="none" stroke="black"></path>
	<path d="M 296,64 L 296,96" fill="none" stroke="black"/>		<path d="M 264,96 L 264,192" fill="none" stroke="black"></path>
	<path d="M 296,192 L 296,224" fill="none" stroke="black"/>		<path d="M 296,64 L 296,96" fill="none" stroke="black"></path>
	<path d="M 312,96 L 312,192" fill="none" stroke="black"/>		<path d="M 296,192 L 296,224" fill="none" stroke="black"></path>
	<path d="M 344,64 L 344,120" fill="none" stroke="black"/>		<path d="M 320,96 L 320,112" fill="none" stroke="black"></path>
	<path d="M 376,96 L 376,192" fill="none" stroke="black"/>		<path d="M 320,176 L 320,192" fill="none" stroke="black"></path>
	<path d="M 424,96 L 424,192" fill="none" stroke="black"/>		<path d="M 344,64 L 344,120" fill="none" stroke="black"></path>
	<path d="M 456,64 L 456,120" fill="none" stroke="black"/>		<path d="M 376,96 L 376,112" fill="none" stroke="black"></path>
	<path d="M 488,96 L 488,192" fill="none" stroke="black"/>		<path d="M 376,176 L 376,192" fill="none" stroke="black"></path>
	<path d="M 544,96 L 544,192" fill="none" stroke="black"/>		<path d="M 424,96 L 424,112" fill="none" stroke="black"></path>
	<path d="M 144,64 L 296,64" fill="none" stroke="black"/>		<path d="M 424,176 L 424,192" fill="none" stroke="black"></path>
	<path d="M 8,96 L 64,96" fill="none" stroke="black"/>		<path d="M 456,64 L 456,120" fill="none" stroke="black"></path>
	<path d="M 128,96 L 176,96" fill="none" stroke="black"/>		<path d="M 488,96 L 488,112" fill="none" stroke="black"></path>
	<path d="M 264,96 L 312,96" fill="none" stroke="black"/>		<path d="M 488,176 L 488,192" fill="none" stroke="black"></path>
	<path d="M 376,96 L 424,96" fill="none" stroke="black"/>		<path d="M 544,96 L 544,192" fill="none" stroke="black"></path>
	<path d="M 488,96 L 544,96" fill="none" stroke="black"/>		<path d="M 136,64 L 296,64" fill="none" stroke="black"></path>
	<path d="M 64,128 L 120,128" fill="none" stroke="black"/>		<path d="M 8,96 L 64,96" fill="none" stroke="black"></path>
	<path d="M 320,128 L 376,128" fill="none" stroke="black"/>		<path d="M 120,96 L 176,96" fill="none" stroke="black"></path>
	<path d="M 64,144 L 120,144" fill="none" stroke="black"/>		<path d="M 264,96 L 320,96" fill="none" stroke="black"></path>
	<path d="M 320,144 L 376,144" fill="none" stroke="black"/>		<path d="M 376,96 L 424,96" fill="none" stroke="black"></path>
	<path d="M 64,160 L 120,160" fill="none" stroke="black"/>		<path d="M 488,96 L 544,96" fill="none" stroke="black"></path>
	<path d="M 320,160 L 376,160" fill="none" stroke="black"/>		<path d="M 72,128 L 112,128" fill="none" stroke="black"></path>
	<path d="M 8,192 L 64,192" fill="none" stroke="black"/>		<path d="M 328,128 L 368,128" fill="none" stroke="black"></path>
	<path d="M 128,192 L 176,192" fill="none" stroke="black"/>		<path d="M 72,144 L 112,144" fill="none" stroke="black"></path>
	<path d="M 264,192 L 312,192" fill="none" stroke="black"/>		<path d="M 328,144 L 368,144" fill="none" stroke="black"></path>
	<path d="M 376,192 L 424,192" fill="none" stroke="black"/>		<path d="M 72,160 L 112,160" fill="none" stroke="black"></path>
	<path d="M 488,192 L 544,192" fill="none" stroke="black"/>		<path d="M 328,160 L 368,160" fill="none" stroke="black"></path>
	<path d="M 144,224 L 296,224" fill="none" stroke="black"/>		<path d="M 8,192 L 64,192" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="464,120 452,114.4 452,125.6"		<path d="M 120,192 L 176,192" fill="none" stroke="black"></path>
	fill="black" transform="rotate(90,456,120)"/>		<path d="M 264,192 L 320,192" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="352,120 340,114.4 340,125.6"		<path d="M 376,192 L 424,192" fill="none" stroke="black"></path>
	fill="black" transform="rotate(90,344,120)"/>		<path d="M 488,192 L 544,192" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="104,120 92,114.4 92,125.6" fi		<path d="M 144,224 L 296,224" fill="none" stroke="black"></path>
	ll="black" transform="rotate(90,96,120)"/>		<polygon class="arrowhead" points="464,120 452,114.4 452,125.6"
	<circle cx="16" cy="272" r="6" class="closeddot" fill="black"/>		fill="black" transform="rotate(90,456,120)"></polygon>
	<circle cx="136" cy="128" r="6" class="closeddot" fill="black"/>		<polygon class="arrowhead" points="352,120 340,114.4 340,125.6"
	<circle cx="136" cy="144" r="6" class="closeddot" fill="black"/>		fill="black" transform="rotate(90,344,120)"></polygon>
	<circle cx="136" cy="160" r="6" class="closeddot" fill="black"/>		<polygon class="arrowhead" points="104,120 92,114.4 92,125.6" fi
	<circle cx="304" cy="128" r="6" class="closeddot" fill="black"/>		ll="black" transform="rotate(90,96,120)"></polygon>
	<circle cx="304" cy="144" r="6" class="closeddot" fill="black"/>		<circle cx="136" cy="128" r="6" class="closeddot" fill="black"><
	<circle cx="304" cy="160" r="6" class="closeddot" fill="black"/>		/circle>
			<circle cx="136" cy="144" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="136" cy="160" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="304" cy="128" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="304" cy="144" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="304" cy="160" r="6" class="closeddot" fill="black"><
			/circle>
	<g class="text">		<g class="text">
	<text x="24" y="36">VLANs</text>		<text x="24" y="36">VLANs</text>
	<text x="100" y="36">representing</text>		<text x="100" y="36">representing</text>
	<text x="180" y="36">slices</text>		<text x="180" y="36">slices</text>
	<text x="312" y="36">VLANs</text>		<text x="312" y="36">VLANs</text>
	<text x="388" y="36">representing</text>		<text x="388" y="36">representing</text>
	<text x="468" y="36">slices</text>		<text x="468" y="36">slices</text>
	<text x="220" y="100">Provider</text>		<text x="220" y="100">Provider</text>
	<text x="456" y="132">.......</text>		<text x="64" y="132">x</text>
			<text x="120" y="132">x</text>
			<text x="320" y="132">x</text>
			<text x="376" y="132">x</text>
			<text x="456" y="132">x.......x</text>
	<text x="28" y="148">NF</text>		<text x="28" y="148">NF</text>
			<text x="64" y="148">x</text>
			<text x="120" y="148">x</text>
	<text x="156" y="148">PE</text>		<text x="156" y="148">PE</text>
	<text x="284" y="148">PE</text>		<text x="284" y="148">PE</text>
	<text x="400" y="148">L2/L3</text>		<text x="320" y="148">x</text>
	<text x="456" y="148">.......</text>		<text x="432" y="148">xL2/L3x.......x</text>
	<text x="524" y="148">NF</text>		<text x="524" y="148">NF</text>
	<text x="456" y="164">.......</text>		<text x="64" y="164">x</text>
	<text x="100" y="196">AC</text>		<text x="120" y="164">x</text>
			<text x="320" y="164">x</text>
			<text x="376" y="164">x</text>
			<text x="456" y="164">x.......x</text>
			<text x="92" y="196">AC</text>
	<text x="224" y="196">Network</text>		<text x="224" y="196">Network</text>
	<text x="348" y="196">AC</text>		<text x="348" y="196">AC</text>
			<text x="16" y="260">x</text>
	<text x="56" y="260">Logical</text>		<text x="56" y="260">Logical</text>
	<text x="128" y="260">interface</text>		<text x="128" y="260">interface</text>
	<text x="216" y="260">represented</text>		<text x="216" y="260">represented</text>
	<text x="276" y="260">by</text>		<text x="276" y="260">by</text>
	<text x="296" y="260">a</text>		<text x="296" y="260">a</text>
	<text x="324" y="260">VLAN</text>		<text x="324" y="260">VLAN</text>
	<text x="356" y="260">on</text>		<text x="356" y="260">on</text>
	<text x="376" y="260">a</text>		<text x="376" y="260">a</text>
	<text x="420" y="260">physical</text>		<text x="420" y="260">physical</text>
	<text x="496" y="260">interface</text>		<text x="496" y="260">interface</text>
			<text x="16" y="276">*</text>
	<text x="40" y="276">SDP</text>		<text x="40" y="276">SDP</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	VLANs representing slices VLANs representing slices		VLANs representing slices VLANs representing slices
	| +------------------+ | |		| +-------------------+ | |
	| | | | |		| | | | |
	+------+ | +-+---+ Provider +---+-+ | +-----+ | +------+		+------+ | +-+----+ Provider +---+--+ | +-----+ | +------+
	| | v | | | | v | | v | |		| | v | | | | v | | v | |
	| +-------+* | | *+-------+ +.......+ |		| x------x * | | * x------x x.......x |
	| NF +-------+* PE | | PE *+-------+L2/L3+.......+ NF |		| NF x------x * PE | | PE * x------xL2/L3x.......x NF |
	| +-------+* | | *+-------+ +.......+ |		| x------x * | | * x------x x.......x |
	| | | | | | | | | |		| | | | | | | | | |
	+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+		+------+ AC +--+---+ Network +---+--+ AC +-----+ +------+
	| |		| |
			------+ AC <span class="insert">+--+---+</span> Network <span class="insert"> +---+--+</span> AC +-----+ +------+
	+------------------+		+------------------+
	+ Logical interface represented by a VLAN on a physical interface		x Logical interface represented by a VLAN on a physical interface
	* SDP		* SDP
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<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 Network Slice might be constructed with multiple such tunnels, si
	typical 5G slice contains many NFs - especially DUs and CUs. If a shared NF (		nce a
	i.e.,		typical 5G Network Slice contains many NFs, especially DUs and CUs. If a shar
	an NF that serves multiple slices, for example, a shared DU) is deployed, mul		ed NF (i.e.,
	tiple		an NF that serves multiple slices, such as a shared DU) is deployed, multiple
	tunnels from shared NF are established, each tunnel representing a single sli		tunnels from the shared NF are established, each tunnel representing a single
	ce.</t>		slice.</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 Network Slice with IP Handoff Providing End-to-End Connectivity</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 2481 ¶
	| | | | | | | | | |		| | | | | | | | | |
	+------+ 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 2588 ¶
	| | | 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>
	<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		<artwork type="svg" align="center">
	000/svg" version="1.1" height="416" width="568" viewBox="0 0 568 416" class="dia		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="416" width="568" v
	gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec		iewBox="0 0 568 416" class="diagram" text-anchor="middle" font-family="monospace
	ap="round">		" font-size="13px" stroke-linecap="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>
	<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>
	<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>
	<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>
	<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>
	<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>
	<path d="M 136,240 L 136,304" fill="none" stroke="black"/>		<path d="M 136,240 L 136,304" fill="none" stroke="black"></pat
	<path d="M 152,208 L 152,240" fill="none" stroke="black"/>		h>
	<path d="M 152,304 L 152,336" fill="none" stroke="black"/>		<path d="M 152,208 L 152,256" fill="none" stroke="black"></pat
	<path d="M 184,240 L 184,304" fill="none" stroke="black"/>		h>
	<path d="M 248,240 L 248,304" fill="none" stroke="black"/>		<path d="M 152,288 L 152,336" fill="none" stroke="black"></pat
	<path d="M 272,208 L 272,240" fill="none" stroke="black"/>		h>
	<path d="M 280,304 L 280,336" fill="none" stroke="black"/>		<path d="M 184,240 L 184,304" fill="none" stroke="black"></pat
	<path d="M 296,240 L 296,304" fill="none" stroke="black"/>		h>
	<path d="M 352,240 L 352,304" fill="none" stroke="black"/>		<path d="M 248,240 L 248,304" fill="none" stroke="black"></pat
	<path d="M 368,208 L 368,240" fill="none" stroke="black"/>		h>
	<path d="M 368,304 L 368,336" fill="none" stroke="black"/>		<path d="M 272,208 L 272,240" fill="none" stroke="black"></pat
	<path d="M 384,192 L 384,240" fill="none" stroke="black"/>		h>
	<path d="M 456,192 L 456,248" fill="none" stroke="black"/>		<path d="M 280,288 L 280,336" fill="none" stroke="black"></pat
	<path d="M 528,240 L 528,304" fill="none" stroke="black"/>		h>
	<path d="M 544,208 L 544,336" fill="none" stroke="black"/>		<path d="M 296,240 L 296,304" fill="none" stroke="black"></pat
	<path d="M 48,32 L 96,32" fill="none" stroke="black"/>		h>
	<path d="M 168,32 L 216,32" fill="none" stroke="black"/>		<path d="M 352,240 L 352,304" fill="none" stroke="black"></pat
	<path d="M 288,32 L 336,32" fill="none" stroke="black"/>		h>
	<path d="M 48,112 L 392,112" fill="none" stroke="black"/>		<path d="M 368,208 L 368,240" fill="none" stroke="black"></pat
	<path d="M 8,208 L 40,208" fill="none" stroke="black"/>		h>
	<path d="M 152,208 L 272,208" fill="none" stroke="black"/>		<path d="M 368,304 L 368,336" fill="none" stroke="black"></pat
	<path d="M 392,208 L 448,208" fill="none" stroke="black"/>		h>
	<path d="M 464,208 L 544,208" fill="none" stroke="black"/>		<path d="M 384,192 L 384,240" fill="none" stroke="black"></pat
	<path d="M 24,240 L 56,240" fill="none" stroke="black"/>		h>
	<path d="M 136,240 L 184,240" fill="none" stroke="black"/>		<path d="M 456,192 L 456,248" fill="none" stroke="black"></pat
	<path d="M 248,240 L 296,240" fill="none" stroke="black"/>		h>
	<path d="M 352,240 L 376,240" fill="none" stroke="black"/>		<path d="M 528,240 L 528,304" fill="none" stroke="black"></pat
	<path d="M 392,240 L 424,240" fill="none" stroke="black"/>		h>
	<path d="M 480,240 L 528,240" fill="none" stroke="black"/>		<path d="M 544,208 L 544,336" fill="none" stroke="black"></pat
	<path d="M 80,272 L 128,272" fill="none" stroke="black"/>		h>
	<path d="M 304,272 L 352,272" fill="none" stroke="black"/>		<path d="M 48,32 L 96,32" fill="none" stroke="black"></path>
	<path d="M 24,304 L 80,304" fill="none" stroke="black"/>		<path d="M 152,32 L 200,32" fill="none" stroke="black"></path>
	<path d="M 136,304 L 184,304" fill="none" stroke="black"/>		<path d="M 272,32 L 320,32" fill="none" stroke="black"></path>
	<path d="M 248,304 L 296,304" fill="none" stroke="black"/>		<path d="M 48,112 L 376,112" fill="none" stroke="black"></path
	<path d="M 352,304 L 424,304" fill="none" stroke="black"/>		>
	<path d="M 480,304 L 528,304" fill="none" stroke="black"/>		<path d="M 8,208 L 40,208" fill="none" stroke="black"></path>
	<path d="M 8,336 L 48,336" fill="none" stroke="black"/>		<path d="M 152,208 L 272,208" fill="none" stroke="black"></pat
	<path d="M 152,336 L 280,336" fill="none" stroke="black"/>		h>
	<path d="M 368,336 L 544,336" fill="none" stroke="black"/>		<path d="M 392,208 L 448,208" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="464,248 452,242.4 452,253.6		h>
	" fill="black" transform="rotate(90,456,248)"/>		<path d="M 464,208 L 544,208" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="400,112 388,106.4 388,117.6		h>
	" fill="black" transform="rotate(0,392,112)"/>		<path d="M 24,240 L 56,240" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="392,240 380,234.4 380,245.6		<path d="M 136,240 L 184,240" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(90,384,240)"/>		h>
	<polygon class="arrowhead" points="296,32 284,26.4 284,37.6" f		<path d="M 248,240 L 296,240" fill="none" stroke="black"></pat
	ill="black" transform="rotate(180,288,32)"/>		h>
	<polygon class="arrowhead" points="288,112 276,106.4 276,117.6		<path d="M 352,240 L 376,240" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,280,112)"/>		h>
	<polygon class="arrowhead" points="280,112 268,106.4 268,117.6		<path d="M 392,240 L 424,240" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(0,272,112)"/>		h>
	<polygon class="arrowhead" points="176,112 164,106.4 164,117.6		<path d="M 480,240 L 528,240" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,168,112)"/>		h>
	<polygon class="arrowhead" points="176,32 164,26.4 164,37.6" f		<path d="M 80,272 L 136,272" fill="none" stroke="black"></path
	ill="black" transform="rotate(180,168,32)"/>		>
	<polygon class="arrowhead" points="168,112 156,106.4 156,117.6		<path d="M 296,272 L 352,272" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(0,160,112)"/>		h>
	<polygon class="arrowhead" points="72,240 60,234.4 60,245.6" f		<path d="M 24,304 L 80,304" fill="none" stroke="black"></path>
	ill="black" transform="rotate(90,64,240)"/>		<path d="M 136,304 L 184,304" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" f		h>
	ill="black" transform="rotate(180,48,112)"/>		<path d="M 248,304 L 296,304" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="56,32 44,26.4 44,37.6" fill		h>
	="black" transform="rotate(180,48,32)"/>		<path d="M 352,304 L 424,304" fill="none" stroke="black"></pat
	<circle cx="24" cy="400" r="6" class="closeddot" fill="black"/		h>
	>		<path d="M 480,304 L 528,304" fill="none" stroke="black"></pat
	<circle cx="144" cy="256" r="6" class="closeddot" fill="black"		h>
	/>		<path d="M 8,336 L 48,336" fill="none" stroke="black"></path>
	<circle cx="144" cy="272" r="6" class="closeddot" fill="black"		<path d="M 152,336 L 280,336" fill="none" stroke="black"></pat
	/>		h>
	<circle cx="144" cy="288" r="6" class="closeddot" fill="black"		<path d="M 368,336 L 544,336" fill="none" stroke="black"></pat
	/>		h>
	<circle cx="288" cy="256" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="464,248 452,242.4 452,253.6
	/>		" fill="black" transform="rotate(90,456,248)"></polygon>
	<circle cx="288" cy="272" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="392,240 380,234.4 380,245.6
	/>		" fill="black" transform="rotate(90,384,240)"></polygon>
	<circle cx="288" cy="288" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="384,112 372,106.4 372,117.6
	/>		" fill="black" transform="rotate(0,376,112)"></polygon>
			<polygon class="arrowhead" points="280,112 268,106.4 268,117.6
			" fill="black" transform="rotate(180,272,112)"></polygon>
			<polygon class="arrowhead" points="280,32 268,26.4 268,37.6" f
			ill="black" transform="rotate(180,272,32)"></polygon>
			<polygon class="arrowhead" points="272,112 260,106.4 260,117.6
			" fill="black" transform="rotate(0,264,112)"></polygon>
			<polygon class="arrowhead" points="160,112 148,106.4 148,117.6
			" fill="black" transform="rotate(180,152,112)"></polygon>
			<polygon class="arrowhead" points="160,32 148,26.4 148,37.6" f
			ill="black" transform="rotate(180,152,32)"></polygon>
			<polygon class="arrowhead" points="152,112 140,106.4 140,117.6
			" fill="black" transform="rotate(0,144,112)"></polygon>
			<polygon class="arrowhead" points="72,240 60,234.4 60,245.6" f
			ill="black" transform="rotate(90,64,240)"></polygon>
			<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" f
			ill="black" transform="rotate(180,48,112)"></polygon>
			<polygon class="arrowhead" points="56,32 44,26.4 44,37.6" fill
			="black" transform="rotate(180,48,32)"></polygon>
			<circle cx="24" cy="400" r="6" class="closeddot" fill="black">
			</circle>
			<circle cx="152" cy="256" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="152" cy="272" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="152" cy="288" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="256" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="272" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="288" r="6" class="closeddot" fill="black"
			></circle>
	<g class="text">		<g class="text">
	<text x="56" y="52">BGP</text>		<text x="56" y="52">BGP</text>
	<text x="88" y="52">VPN</text>		<text x="88" y="52">VPN</text>
	<text x="176" y="52">BGP</text>		<text x="176" y="52">BGP</text>
	<text x="208" y="52">VPN</text>		<text x="208" y="52">VPN</text>
	<text x="296" y="52">BGP</text>		<text x="296" y="52">BGP</text>
	<text x="328" y="52">VPN</text>		<text x="328" y="52">VPN</text>
	<text x="84" y="68">COM=1,</text>		<text x="84" y="68">COM=1,</text>
	<text x="132" y="68">L=A"</text>		<text x="132" y="68">L=A"</text>
	<text x="204" y="68">COM=1,</text>		<text x="204" y="68">COM=1,</text>
	skipping to change at line 2450 ¶		skipping to change at line 2719 ¶
	<text x="316" y="180">representing</text>		<text x="316" y="180">representing</text>
	<text x="396" y="180">slices</text>		<text x="396" y="180">slices</text>
	<text x="476" y="180">slices</text>		<text x="476" y="180">slices</text>
	<text x="376" y="212">-</text>		<text x="376" y="212">-</text>
	<text x="228" y="228">Provider</text>		<text x="228" y="228">Provider</text>
	<text x="72" y="244">-</text>		<text x="72" y="244">-</text>
	<text x="64" y="260">#</text>		<text x="64" y="260">#</text>
	<text x="432" y="260">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="260">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="44" y="276">NF</text>		<text x="44" y="276">NF</text>
	<text x="64" y="276">#</text>		<text x="64" y="276">#</text>
	<text x="164" y="276">PE</text>		<text x="172" y="276">PE</text>
	<text x="268" y="276">PE</text>		<text x="260" y="276">PE</text>
	<text x="432" y="276">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="276">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="508" y="276">NF</text>		<text x="508" y="276">NF</text>
	<text x="64" y="292">#</text>		<text x="64" y="292">#</text>
	<text x="116" y="292">AC</text>		<text x="116" y="292">AC</text>
	<text x="332" y="292">AC</text>		<text x="332" y="292">AC</text>
	<text x="432" y="292">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="292">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="32" y="324">CS1</text>		<text x="32" y="324">CS1</text>
	<text x="216" y="324">Network</text>		<text x="216" y="324">Network</text>
	<text x="400" y="324">L2/L3</text>		<text x="400" y="324">L2/L3</text>
	<text x="464" y="324">CS2</text>		<text x="464" y="324">CS2</text>
	skipping to change at line 2483 ¶		skipping to change at line 2752 ¶
	<text x="24" y="388">#</text>		<text x="24" y="388">#</text>
	<text x="64" y="388">Service</text>		<text x="64" y="388">Service</text>
	<text x="136" y="388">instances</text>		<text x="136" y="388">instances</text>
	<text x="200" y="388">(with</text>		<text x="200" y="388">(with</text>
	<text x="252" y="388">unique</text>		<text x="252" y="388">unique</text>
	<text x="300" y="388">MPLS</text>		<text x="300" y="388">MPLS</text>
	<text x="352" y="388">labels)</text>		<text x="352" y="388">labels)</text>
	<text x="48" y="404">SDP</text>		<text x="48" y="404">SDP</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	<------ <------ <------		<------ <------ <------
	BGP VPN BGP VPN BGP VPN		BGP VPN BGP VPN BGP VPN
	COM=1, L=A" COM=1, L=A' COM=1, L=A		COM=1, L=A" COM=1, L=A' COM=1, L=A
	COM=2, L=B" COM=2, L=B' COM=2, L=B		COM=2, L=B" COM=2, L=B' COM=2, L=B
	COM=3, L=C" COM=3, L=C' COM=3, L=C		COM=3, L=C" COM=3, L=C' COM=3, L=C
	<-------------><------------><------------->		<-----------><-------------><------------>
	nhs nhs nhs nhs		nhs nhs nhs nhs
	VLANs		VLANs
	service instances service instances representing		service instances service instances representing
	representing slices representing slices slices		representing slices representing slices slices
	| | |		| | |
	+---+ | +--------------+ +-|--------|----------+		+---+ | +--------------+ +-|--------|----------+
	| | | | Provider | | | | |		| | | | Provider | | | | |
	| +-+--v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ |		| +-+--v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ |
	| | # | |* | | *| | #<><>x......x | |		| | # | | * | | * | | #<><>x......x | |
	| | NF # +------+* PE | | PE *+------+ #<><>x......x NF | |		| | NF # +------+ * PE| |PE * +------+ #<><>x......x NF | |
	| | # | AC |* | | *| AC | #<><>x......x | |		| | # | AC | * | | * | AC | #<><>x......x | |
	| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ |		| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ |
	| 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>
	skipping to change at line 2512 ¶		skipping to change at line 2782 ¶
	| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ |		| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ |
	| 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>
	<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		<artwork type="svg" align="center">
	000/svg" version="1.1" height="496" width="552" viewBox="0 0 552 496" class="dia		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="496" width="552" v
	gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec		iewBox="0 0 552 496" class="diagram" text-anchor="middle" font-family="monospace
	ap="round">		" font-size="13px" stroke-linecap="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>
	<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>
	<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>
	<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>
	<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>
	<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>
	<path d="M 136,320 L 136,384" fill="none" stroke="black"/>		<path d="M 136,320 L 136,384" fill="none" stroke="black"></pat
	<path d="M 152,288 L 152,320" fill="none" stroke="black"/>		h>
	<path d="M 152,384 L 152,416" fill="none" stroke="black"/>		<path d="M 152,288 L 152,336" fill="none" stroke="black"></pat
	<path d="M 184,320 L 184,384" fill="none" stroke="black"/>		h>
	<path d="M 248,320 L 248,384" fill="none" stroke="black"/>		<path d="M 152,368 L 152,416" fill="none" stroke="black"></pat
	<path d="M 272,288 L 272,320" fill="none" stroke="black"/>		h>
	<path d="M 280,384 L 280,416" fill="none" stroke="black"/>		<path d="M 184,320 L 184,384" fill="none" stroke="black"></pat
	<path d="M 296,320 L 296,384" fill="none" stroke="black"/>		h>
	<path d="M 352,320 L 352,384" fill="none" stroke="black"/>		<path d="M 248,320 L 248,384" fill="none" stroke="black"></pat
	<path d="M 368,288 L 368,320" fill="none" stroke="black"/>		h>
	<path d="M 368,384 L 368,416" fill="none" stroke="black"/>		<path d="M 272,288 L 272,320" fill="none" stroke="black"></pat
	<path d="M 384,272 L 384,320" fill="none" stroke="black"/>		h>
	<path d="M 456,272 L 456,328" fill="none" stroke="black"/>		<path d="M 280,368 L 280,416" fill="none" stroke="black"></pat
	<path d="M 528,320 L 528,384" fill="none" stroke="black"/>		h>
	<path d="M 544,288 L 544,416" fill="none" stroke="black"/>		<path d="M 296,320 L 296,384" fill="none" stroke="black"></pat
	<path d="M 48,32 L 392,32" fill="none" stroke="black"/>		h>
	<path d="M 48,112 L 392,112" fill="none" stroke="black"/>		<path d="M 352,320 L 352,384" fill="none" stroke="black"></pat
	<path d="M 56,144 L 104,144" fill="none" stroke="black"/>		h>
	<path d="M 176,144 L 224,144" fill="none" stroke="black"/>		<path d="M 368,288 L 368,320" fill="none" stroke="black"></pat
	<path d="M 296,144 L 344,144" fill="none" stroke="black"/>		h>
	<path d="M 48,192 L 392,192" fill="none" stroke="black"/>		<path d="M 368,384 L 368,416" fill="none" stroke="black"></pat
	<path d="M 8,288 L 40,288" fill="none" stroke="black"/>		h>
	<path d="M 152,288 L 272,288" fill="none" stroke="black"/>		<path d="M 384,272 L 384,320" fill="none" stroke="black"></pat
	<path d="M 392,288 L 448,288" fill="none" stroke="black"/>		h>
	<path d="M 464,288 L 544,288" fill="none" stroke="black"/>		<path d="M 456,272 L 456,328" fill="none" stroke="black"></pat
	<path d="M 24,320 L 48,320" fill="none" stroke="black"/>		h>
	<path d="M 136,320 L 184,320" fill="none" stroke="black"/>		<path d="M 528,320 L 528,384" fill="none" stroke="black"></pat
	<path d="M 248,320 L 296,320" fill="none" stroke="black"/>		h>
	<path d="M 352,320 L 376,320" fill="none" stroke="black"/>		<path d="M 544,288 L 544,416" fill="none" stroke="black"></pat
	<path d="M 392,320 L 424,320" fill="none" stroke="black"/>		h>
	<path d="M 480,320 L 528,320" fill="none" stroke="black"/>		<path d="M 48,32 L 368,32" fill="none" stroke="black"></path>
	<path d="M 72,352 L 128,352" fill="none" stroke="black"/>		<path d="M 48,112 L 368,112" fill="none" stroke="black"></path
	<path d="M 304,352 L 352,352" fill="none" stroke="black"/>		>
	<path d="M 24,384 L 72,384" fill="none" stroke="black"/>		<path d="M 56,144 L 104,144" fill="none" stroke="black"></path
	<path d="M 136,384 L 184,384" fill="none" stroke="black"/>		>
	<path d="M 248,384 L 296,384" fill="none" stroke="black"/>		<path d="M 176,144 L 224,144" fill="none" stroke="black"></pat
	<path d="M 352,384 L 424,384" fill="none" stroke="black"/>		h>
	<path d="M 480,384 L 528,384" fill="none" stroke="black"/>		<path d="M 296,144 L 344,144" fill="none" stroke="black"></pat
	<path d="M 8,416 L 48,416" fill="none" stroke="black"/>		h>
	<path d="M 152,416 L 280,416" fill="none" stroke="black"/>		<path d="M 48,192 L 368,192" fill="none" stroke="black"></path
	<path d="M 368,416 L 544,416" fill="none" stroke="black"/>		>
	<polygon class="arrowhead" points="464,328 452,322.4 452,333.6		<path d="M 8,288 L 40,288" fill="none" stroke="black"></path>
	" fill="black" transform="rotate(90,456,328)"/>		<path d="M 152,288 L 272,288" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="400,192 388,186.4 388,197.6		h>
	" fill="black" transform="rotate(0,392,192)"/>		<path d="M 392,288 L 448,288" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="400,112 388,106.4 388,117.6		h>
	" fill="black" transform="rotate(0,392,112)"/>		<path d="M 464,288 L 544,288" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="392,320 380,314.4 380,325.6		h>
	" fill="black" transform="rotate(90,384,320)"/>		<path d="M 24,320 L 48,320" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="304,144 292,138.4 292,149.6		<path d="M 136,320 L 184,320" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,296,144)"/>		h>
	<polygon class="arrowhead" points="288,192 276,186.4 276,197.6		<path d="M 248,320 L 296,320" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,280,192)"/>		h>
	<polygon class="arrowhead" points="280,192 268,186.4 268,197.6		<path d="M 352,320 L 376,320" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(0,272,192)"/>		h>
	<polygon class="arrowhead" points="184,144 172,138.4 172,149.6		<path d="M 392,320 L 424,320" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,176,144)"/>		h>
	<polygon class="arrowhead" points="176,192 164,186.4 164,197.6		<path d="M 480,320 L 528,320" fill="none" stroke="black"></pat
	" fill="black" transform="rotate(180,168,192)"/>		h>
	<polygon class="arrowhead" points="168,192 156,186.4 156,197.6		<path d="M 72,352 L 136,352" fill="none" stroke="black"></path
	" fill="black" transform="rotate(0,160,192)"/>		>
	<polygon class="arrowhead" points="64,320 52,314.4 52,325.6" f		<path d="M 296,352 L 352,352" fill="none" stroke="black"></pat
	ill="black" transform="rotate(90,56,320)"/>		h>
	<polygon class="arrowhead" points="64,144 52,138.4 52,149.6" f		<path d="M 24,384 L 72,384" fill="none" stroke="black"></path>
	ill="black" transform="rotate(180,56,144)"/>		<path d="M 136,384 L 184,384" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="56,192 44,186.4 44,197.6" f		h>
	ill="black" transform="rotate(180,48,192)"/>		<path d="M 248,384 L 296,384" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" f		h>
	ill="black" transform="rotate(180,48,112)"/>		<path d="M 352,384 L 424,384" fill="none" stroke="black"></pat
	<polygon class="arrowhead" points="56,32 44,26.4 44,37.6" fill		h>
	="black" transform="rotate(180,48,32)"/>		<path d="M 480,384 L 528,384" fill="none" stroke="black"></pat
	<circle cx="32" cy="480" r="6" class="closeddot" fill="black"/		h>
	>		<path d="M 8,416 L 48,416" fill="none" stroke="black"></path>
	<circle cx="144" cy="336" r="6" class="closeddot" fill="black"		<path d="M 152,416 L 280,416" fill="none" stroke="black"></pat
	/>		h>
	<circle cx="144" cy="352" r="6" class="closeddot" fill="black"		<path d="M 368,416 L 544,416" fill="none" stroke="black"></pat
	/>		h>
	<circle cx="144" cy="368" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="464,328 452,322.4 452,333.6
	/>		" fill="black" transform="rotate(90,456,328)"></polygon>
	<circle cx="288" cy="336" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="392,320 380,314.4 380,325.6
	/>		" fill="black" transform="rotate(90,384,320)"></polygon>
	<circle cx="288" cy="352" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="376,192 364,186.4 364,197.6
	/>		" fill="black" transform="rotate(0,368,192)"></polygon>
	<circle cx="288" cy="368" r="6" class="closeddot" fill="black"		<polygon class="arrowhead" points="376,112 364,106.4 364,117.6
	/>		" fill="black" transform="rotate(0,368,112)"></polygon>
			<polygon class="arrowhead" points="304,144 292,138.4 292,149.6
			" fill="black" transform="rotate(180,296,144)"></polygon>
			<polygon class="arrowhead" points="288,192 276,186.4 276,197.6
			" fill="black" transform="rotate(180,280,192)"></polygon>
			<polygon class="arrowhead" points="280,192 268,186.4 268,197.6
			" fill="black" transform="rotate(0,272,192)"></polygon>
			<polygon class="arrowhead" points="184,144 172,138.4 172,149.6
			" fill="black" transform="rotate(180,176,144)"></polygon>
			<polygon class="arrowhead" points="160,192 148,186.4 148,197.6
			" fill="black" transform="rotate(180,152,192)"></polygon>
			<polygon class="arrowhead" points="152,192 140,186.4 140,197.6
			" fill="black" transform="rotate(0,144,192)"></polygon>
			<polygon class="arrowhead" points="64,320 52,314.4 52,325.6" f
			ill="black" transform="rotate(90,56,320)"></polygon>
			<polygon class="arrowhead" points="64,144 52,138.4 52,149.6" f
			ill="black" transform="rotate(180,56,144)"></polygon>
			<polygon class="arrowhead" points="56,192 44,186.4 44,197.6" f
			ill="black" transform="rotate(180,48,192)"></polygon>
			<polygon class="arrowhead" points="56,112 44,106.4 44,117.6" f
			ill="black" transform="rotate(180,48,112)"></polygon>
			<polygon class="arrowhead" points="56,32 44,26.4 44,37.6" fill
			="black" transform="rotate(180,48,32)"></polygon>
			<circle cx="32" cy="480" r="6" class="closeddot" fill="black">
			</circle>
			<circle cx="152" cy="336" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="152" cy="352" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="152" cy="368" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="336" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="352" r="6" class="closeddot" fill="black"
			></circle>
			<circle cx="280" cy="368" r="6" class="closeddot" fill="black"
			></circle>
	<g class="text">		<g class="text">
	<text x="120" y="52">BGP</text>		<text x="120" y="52">BGP</text>
	<text x="152" y="52">VPN</text>		<text x="152" y="52">VPN</text>
	<text x="148" y="68">COM=1,</text>		<text x="148" y="68">COM=1,</text>
	<text x="196" y="68">L=A,</text>		<text x="196" y="68">L=A,</text>
	<text x="268" y="68">NEXT_HOP=CS2</text>		<text x="268" y="68">NEXT_HOP=CS2</text>
	<text x="148" y="84">COM=2,</text>		<text x="148" y="84">COM=2,</text>
	<text x="196" y="84">L=B,</text>		<text x="196" y="84">L=B,</text>
	<text x="268" y="84">NEXT_HOP=CS2</text>		<text x="268" y="84">NEXT_HOP=CS2</text>
	<text x="148" y="100">COM=3,</text>		<text x="148" y="100">COM=3,</text>
	skipping to change at line 2651 ¶		skipping to change at line 2922 ¶
	<text x="184" y="164">BGP</text>		<text x="184" y="164">BGP</text>
	<text x="212" y="164">LU</text>		<text x="212" y="164">LU</text>
	<text x="304" y="164">BGP</text>		<text x="304" y="164">BGP</text>
	<text x="332" y="164">LU</text>		<text x="332" y="164">LU</text>
	<text x="84" y="180">CS2,</text>		<text x="84" y="180">CS2,</text>
	<text x="124" y="180">L=X"</text>		<text x="124" y="180">L=X"</text>
	<text x="204" y="180">CS2,</text>		<text x="204" y="180">CS2,</text>
	<text x="244" y="180">L=X'</text>		<text x="244" y="180">L=X'</text>
	<text x="324" y="180">CS2,</text>		<text x="324" y="180">CS2,</text>
	<text x="360" y="180">L=X</text>		<text x="360" y="180">L=X</text>
	<text x="144" y="212">nhs</text>		<text x="128" y="212">nhs</text>
	<text x="184" y="212">nhs</text>		<text x="168" y="212">nhs</text>
	<text x="256" y="212">nhs</text>		<text x="256" y="212">nhs</text>
	<text x="296" y="212">nhs</text>		<text x="296" y="212">nhs</text>
	<text x="472" y="228">VLANs</text>		<text x="472" y="228">VLANs</text>
	<text x="32" y="244">service</text>		<text x="32" y="244">service</text>
	<text x="104" y="244">instances</text>		<text x="104" y="244">instances</text>
	<text x="296" y="244">service</text>		<text x="296" y="244">service</text>
	<text x="368" y="244">instances</text>		<text x="368" y="244">instances</text>
	<text x="468" y="244">representing</text>		<text x="468" y="244">representing</text>
	<text x="52" y="260">representing</text>		<text x="52" y="260">representing</text>
	<text x="132" y="260">slices</text>		<text x="132" y="260">slices</text>
	<text x="316" y="260">representing</text>		<text x="316" y="260">representing</text>
	<text x="396" y="260">slices</text>		<text x="396" y="260">slices</text>
	<text x="476" y="260">slices</text>		<text x="476" y="260">slices</text>
	<text x="376" y="292">-</text>		<text x="376" y="292">-</text>
	<text x="228" y="308">Provider</text>		<text x="228" y="308">Provider</text>
	<text x="64" y="324">-</text>		<text x="64" y="324">-</text>
	<text x="56" y="340">#</text>		<text x="56" y="340">#</text>
	<text x="432" y="340">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="340">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="36" y="356">NF</text>		<text x="36" y="356">NF</text>
	<text x="56" y="356">#</text>		<text x="56" y="356">#</text>
	<text x="164" y="356">PE</text>		<text x="172" y="356">PE</text>
	<text x="268" y="356">PE</text>		<text x="260" y="356">PE</text>
	<text x="432" y="356">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="356">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="508" y="356">NF</text>		<text x="508" y="356">NF</text>
	<text x="56" y="372">#</text>		<text x="56" y="372">#</text>
	<text x="108" y="372">AC</text>		<text x="108" y="372">AC</text>
	<text x="332" y="372">AC</text>		<text x="332" y="372">AC</text>
	<text x="432" y="372">#&lt;&gt;&lt;&gt;x......x</text>		<text x="432" y="372">#&lt;&gt;&lt;&gt;x......x</text>
	<text x="32" y="404">CS1</text>		<text x="32" y="404">CS1</text>
	<text x="232" y="404">Network</text>		<text x="232" y="404">Network</text>
	<text x="400" y="404">L2/L3</text>		<text x="400" y="404">L2/L3</text>
	<text x="464" y="404">CS2</text>		<text x="464" y="404">CS2</text>
	skipping to change at line 2706 ¶		skipping to change at line 2977 ¶
	<text x="32" y="468">#</text>		<text x="32" y="468">#</text>
	<text x="72" y="468">Service</text>		<text x="72" y="468">Service</text>
	<text x="144" y="468">instances</text>		<text x="144" y="468">instances</text>
	<text x="208" y="468">(with</text>		<text x="208" y="468">(with</text>
	<text x="260" y="468">unique</text>		<text x="260" y="468">unique</text>
	<text x="308" y="468">MPLS</text>		<text x="308" y="468">MPLS</text>
	<text x="356" y="468">label)</text>		<text x="356" y="468">label)</text>
	<text x="56" y="484">SDP</text>		<text x="56" y="484">SDP</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	<-------------------------------------------		<----------------------------------------
	BGP VPN		BGP VPN
	COM=1, L=A, NEXT_HOP=CS2		COM=1, L=A, NEXT_HOP=CS2
	COM=2, L=B, NEXT_HOP=CS2		COM=2, L=B, NEXT_HOP=CS2
	COM=3, L=C, NEXT_HOP=CS2		COM=3, L=C, NEXT_HOP=CS2
	<------------------------------------------>		<--------------------------------------->
	<------ <------ <------		<------ <------ <------
	BGP LU BGP LU BGP LU		BGP LU BGP LU BGP LU
	CS2, L=X" CS2, L=X' CS2, L=X		CS2, L=X" CS2, L=X' CS2, L=X
	<-------------><------------><------------->		<-----------><--------------><---------->
	nhs nhs nhs nhs		nhs nhs nhs nhs
	VLANs		VLANs
	service instances service instances representing		service instances service instances representing
	representing slices representing slices slices		representing slices representing slices slices
	| | |		| | |
	+---+ | +--------------+ +-|--------|----------+		+---+ | +--------------+ +-|--------|----------+
	| | | | Provider | | | | |		| | | | Provider | | | | |
	| +-+-v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ |		| +-+-v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ |
	| | # | |* | | *| | #<><>x......x | |		| | # | | * | | * | | #<><>x......x | |
	| |NF # +-------+* PE | | PE *+------+ #<><>x......x NF | |		| |NF # +-------+ * PE| |PE * +------+ #<><>x......x NF | |
	| | # | AC |* | | *| AC | #<><>x......x | |		| | # | AC | * | | * | AC | #<><>x......x | |
	| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ |		| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ |
	| 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>
	skipping to change at line 2740 ¶		skipping to change at line 3012 ¶
	| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ |		| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ |
	| 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>
	<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.
	el swap		Appropriate forwarding entries for label swaps
	forwarding entries for IPv4/IPv6 labeled unicast labels are programmed in the da		for IPv4/IPv6 labeled unicast labels are programmed in the data
	ta plane.		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		<t>Packets are transmitted over the AC with the IPv4/IPv6 labeled
	n C,		unicast as the top label, with the service label deeper in the label stack. In O
	the service label is not used for forwarding lookup on the PE. This significantl		ption C,
	y		the service label is not used for forwarding lookup on the PE.
	lowers the scaling pressure on PEs, as PEs need to program forwarding entries on		This significantly lowers the scaling pressure on PEs, as PEs need to
	ly for		program forwarding entries only for IPv4/IPv6 labeled unicast host routes,
	IPv4/IPv6 labeled unicast host routes, used as NEXT_HOP for service prefixes. Al		which are used as NEXT_HOP for service prefixes.
	so,		Also,
	since one IPv4/IPv6 labeled unicast host route represent one customer site, rega		since one IPv4/IPv6 labeled unicast host route represents one customer site, reg
	rdless		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 Network 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 Network 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 Network Slices (for example, only two 5G Network 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 Network Slices (and thus the corresponding RFC 95 43
	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 3383 ¶
	| '--------------' | |		| '--------------' | |
	+-------------------' |		+-------------------' |
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	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		<t>The original IP header retains the DSCP marking (which is ignored i
	5QI-unaware model), while the new header (MPLS or IPv6) carries QoS		n the
	marking (MPLS Traffic Class bits for MPLS encapsulation, or DSCP for		5QI-unaware model), while the new header (MPLS or IPv6) carries the QoS
	SRv6/IPv6 encapsulation) related to TN Class of Service (CoS). Based on TN C		marking (MPLS Traffic Class bits for MPLS encapsulation or DSCP for
	oS		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 3208 ¶		skipping to change at line 3486 ¶
	|(GTP-U/IPsec) | / |(GTP-U/IPsec) |		|(GTP-U/IPsec) | / |(GTP-U/IPsec) |
	| | / | |		| | / | |
	| |---------+ / | |		| |---------+ / | |
	| | | / | |		| | | / | |
	| | |/ | |		| | |/ | |
	+--------------+ - - - - - - - - +--------------+		+--------------+ - - - - - - - - +--------------+
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<figure anchor="_figure-16">		<figure anchor="_figure-16">
	<name>QoS with IPv6 Encapsulation</name>		<name>QoS with SRv6 Encapsulation</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="400" width="400" viewBox="0 0 400 400" 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="400" width="400" viewBox="0 0 400 400" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
	<path d="M 8,160 L 8,384" fill="none" stroke="black"/>		<path d="M 8,160 L 8,384" fill="none" stroke="black"/>
	<path d="M 64,192 L 64,224" fill="none" stroke="black"/>		<path d="M 64,192 L 64,224" fill="none" stroke="black"/>
	<path d="M 128,160 L 128,384" fill="none" stroke="black"/>		<path d="M 128,160 L 128,384" fill="none" stroke="black"/>
	<path d="M 208,168 L 208,208" fill="none" stroke="black"/>		<path d="M 208,168 L 208,208" fill="none" stroke="black"/>
	<path d="M 208,336 L 208,376" fill="none" stroke="black"/>		<path d="M 208,336 L 208,376" fill="none" stroke="black"/>
	<path d="M 272,32 L 272,96" fill="none" stroke="black"/>		<path d="M 272,32 L 272,96" fill="none" stroke="black"/>
	<path d="M 272,160 L 272,384" fill="none" stroke="black"/>		<path d="M 272,160 L 272,384" fill="none" stroke="black"/>
	<path d="M 328,64 L 328,96" fill="none" stroke="black"/>		<path d="M 328,64 L 328,96" fill="none" stroke="black"/>
	skipping to change at line 3313 ¶		skipping to change at line 3591 ¶
	| | | / | |		| | | / | |
	| | |/ | |		| | |/ | |
	+--------------+ - - - - - - - - +--------------+		+--------------+ - - - - - - - - +--------------+
	]]></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
			<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>
	<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
	odel, where all packets		<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		5G 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 3802 ¶
	<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 4054 ¶
	<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 Network 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 5G 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 4146 ¶		skipping to change at line 4426 ¶
	| '--------------' | |		| '--------------' | |
	+-------------------+ |		+-------------------+ |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	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		Network 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		<artwork type="svg" align="center">
	000/svg" version="1.1" height="512" width="520" viewBox="0 0 520 512" class="dia		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="512" width="544" v
	gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec		iewBox="0 0 544 512" class="diagram" text-anchor="middle" font-family="monospace
	ap="round">		" font-size="13px" stroke-linecap="round">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<path d="M 8,48 L 8,240" fill="none" stroke="black"></path>
	<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>
	<path d="M 8,272 L 8,464" fill="none" stroke="black"/>		<path d="M 208,48 L 208,104" fill="none" stroke="black"></path
	<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 208,120 L 208,152" fill="none" stroke="black"></pat
	<path d="M 184,168 L 184,200" fill="none" stroke="black"/>		h>
	<path d="M 184,216 L 184,240" fill="none" stroke="black"/>		<path d="M 208,168 L 208,200" fill="none" stroke="black"></pat
	<path d="M 184,272 L 184,328" fill="none" stroke="black"/>		h>
	<path d="M 184,344 L 184,376" fill="none" stroke="black"/>		<path d="M 208,216 L 208,240" fill="none" stroke="black"></pat
	<path d="M 184,392 L 184,424" fill="none" stroke="black"/>		h>
	<path d="M 184,440 L 184,464" fill="none" stroke="black"/>		<path d="M 208,272 L 208,328" fill="none" stroke="black"></pat
	<path d="M 200,32 L 200,104" fill="none" stroke="black"/>		h>
	<path d="M 200,120 L 200,152" fill="none" stroke="black"/>		<path d="M 208,344 L 208,376" fill="none" stroke="black"></pat
	<path d="M 200,168 L 200,200" fill="none" stroke="black"/>		h>
	<path d="M 200,216 L 200,328" fill="none" stroke="black"/>		<path d="M 208,392 L 208,424" fill="none" stroke="black"></pat
	<path d="M 200,344 L 200,376" fill="none" stroke="black"/>		h>
	<path d="M 200,392 L 200,424" fill="none" stroke="black"/>		<path d="M 208,440 L 208,464" fill="none" stroke="black"></pat
	<path d="M 200,440 L 200,480" fill="none" stroke="black"/>		h>
	<path d="M 216,80 L 216,104" fill="none" stroke="black"/>		<path d="M 224,32 L 224,104" fill="none" stroke="black"></path
	<path d="M 216,120 L 216,152" fill="none" stroke="black"/>		>
	<path d="M 216,168 L 216,200" fill="none" stroke="black"/>		<path d="M 224,120 L 224,152" fill="none" stroke="black"></pat
	<path d="M 216,216 L 216,240" fill="none" stroke="black"/>		h>
	<path d="M 216,304 L 216,328" fill="none" stroke="black"/>		<path d="M 224,168 L 224,200" fill="none" stroke="black"></pat
	<path d="M 216,344 L 216,376" fill="none" stroke="black"/>		h>
	<path d="M 216,392 L 216,424" fill="none" stroke="black"/>		<path d="M 224,216 L 224,328" fill="none" stroke="black"></pat
	<path d="M 216,440 L 216,464" fill="none" stroke="black"/>		h>
	<path d="M 312,64 L 312,104" fill="none" stroke="black"/>		<path d="M 224,344 L 224,376" fill="none" stroke="black"></pat
	<path d="M 312,120 L 312,152" fill="none" stroke="black"/>		h>
	<path d="M 312,168 L 312,200" fill="none" stroke="black"/>		<path d="M 224,392 L 224,424" fill="none" stroke="black"></pat
	<path d="M 312,216 L 312,224" fill="none" stroke="black"/>		h>
	<path d="M 312,288 L 312,328" fill="none" stroke="black"/>		<path d="M 224,440 L 224,480" fill="none" stroke="black"></pat
	<path d="M 312,344 L 312,376" fill="none" stroke="black"/>		h>
	<path d="M 312,392 L 312,424" fill="none" stroke="black"/>		<path d="M 240,80 L 240,96" fill="none" stroke="black"></path>
	<path d="M 312,440 L 312,448" fill="none" stroke="black"/>		<path d="M 240,128 L 240,144" fill="none" stroke="black"></pat
	<path d="M 336,112 L 336,200" fill="none" stroke="black"/>		h>
	<path d="M 336,216 L 336,384" fill="none" stroke="black"/>		<path d="M 240,176 L 240,192" fill="none" stroke="black"></pat
	<path d="M 352,208 L 352,232" fill="none" stroke="black"/>		h>
	<path d="M 352,248 L 352,432" fill="none" stroke="black"/>		<path d="M 240,224 L 240,240" fill="none" stroke="black"></pat
	<path d="M 496,224 L 496,240" fill="none" stroke="black"/>		h>
	<path d="M 496,352 L 496,368" fill="none" stroke="black"/>		<path d="M 240,304 L 240,320" fill="none" stroke="black"></pat
	<path d="M 512,32 L 512,480" fill="none" stroke="black"/>		h>
	<path d="M 200,32 L 320,32" fill="none" stroke="black"/>		<path d="M 240,352 L 240,368" fill="none" stroke="black"></pat
	<path d="M 376,32 L 512,32" fill="none" stroke="black"/>		h>
	<path d="M 8,48 L 56,48" fill="none" stroke="black"/>		<path d="M 240,400 L 240,416" fill="none" stroke="black"></pat
	<path d="M 112,48 L 184,48" fill="none" stroke="black"/>		h>
	<path d="M 232,64 L 312,64" fill="none" stroke="black"/>		<path d="M 240,448 L 240,464" fill="none" stroke="black"></pat
	<path d="M 40,96 L 88,96" fill="none" stroke="black"/>		h>
	<path d="M 104,96 L 160,96" fill="none" stroke="black"/>		<path d="M 336,64 L 336,104" fill="none" stroke="black"></path
	<path d="M 232,96 L 288,96" fill="none" stroke="black"/>		>
	<path d="M 80,112 L 96,112" fill="none" stroke="black"/>		<path d="M 336,120 L 336,152" fill="none" stroke="black"></pat
	<path d="M 176,112 L 232,112" fill="none" stroke="black"/>		h>
	<path d="M 304,112 L 336,112" fill="none" stroke="black"/>		<path d="M 336,168 L 336,200" fill="none" stroke="black"></pat
	<path d="M 40,128 L 88,128" fill="none" stroke="black"/>		h>
	<path d="M 104,128 L 160,128" fill="none" stroke="black"/>		<path d="M 336,288 L 336,328" fill="none" stroke="black"></pat
	<path d="M 232,128 L 288,128" fill="none" stroke="black"/>		h>
	<path d="M 40,144 L 88,144" fill="none" stroke="black"/>		<path d="M 336,344 L 336,376" fill="none" stroke="black"></pat
	<path d="M 104,144 L 160,144" fill="none" stroke="black"/>		h>
	<path d="M 232,144 L 288,144" fill="none" stroke="black"/>		<path d="M 336,392 L 336,424" fill="none" stroke="black"></pat
	<path d="M 80,160 L 96,160" fill="none" stroke="black"/>		h>
	<path d="M 176,160 L 232,160" fill="none" stroke="black"/>		<path d="M 336,440 L 336,448" fill="none" stroke="black"></pat
	<path d="M 304,160 L 336,160" fill="none" stroke="black"/>		h>
	<path d="M 40,176 L 88,176" fill="none" stroke="black"/>		<path d="M 360,112 L 360,200" fill="none" stroke="black"></pat
	<path d="M 104,176 L 160,176" fill="none" stroke="black"/>		h>
	<path d="M 232,176 L 288,176" fill="none" stroke="black"/>		<path d="M 360,216 L 360,384" fill="none" stroke="black"></pat
	<path d="M 40,192 L 88,192" fill="none" stroke="black"/>		h>
	<path d="M 104,192 L 160,192" fill="none" stroke="black"/>		<path d="M 376,208 L 376,232" fill="none" stroke="black"></pat
	<path d="M 232,192 L 288,192" fill="none" stroke="black"/>		h>
	<path d="M 80,208 L 96,208" fill="none" stroke="black"/>		<path d="M 376,248 L 376,432" fill="none" stroke="black"></pat
	<path d="M 176,208 L 232,208" fill="none" stroke="black"/>		h>
	<path d="M 304,208 L 352,208" fill="none" stroke="black"/>		<path d="M 520,224 L 520,240" fill="none" stroke="black"></pat
	<path d="M 392,208 L 480,208" fill="none" stroke="black"/>		h>
	<path d="M 40,224 L 88,224" fill="none" stroke="black"/>		<path d="M 520,352 L 520,368" fill="none" stroke="black"></pat
	<path d="M 104,224 L 160,224" fill="none" stroke="black"/>		h>
	<path d="M 232,224 L 288,224" fill="none" stroke="black"/>		<path d="M 536,32 L 536,480" fill="none" stroke="black"></path
	<path d="M 8,240 L 184,240" fill="none" stroke="black"/>		>
	<path d="M 216,240 L 296,240" fill="none" stroke="black"/>		<path d="M 224,32 L 344,32" fill="none" stroke="black"></path>
	<path d="M 336,240 L 376,240" fill="none" stroke="black"/>		<path d="M 400,32 L 536,32" fill="none" stroke="black"></path>
	<path d="M 384,256 L 480,256" fill="none" stroke="black"/>		<path d="M 8,48 L 56,48" fill="none" stroke="black"></path>
	<path d="M 8,272 L 64,272" fill="none" stroke="black"/>		<path d="M 112,48 L 208,48" fill="none" stroke="black"></path>
	<path d="M 120,272 L 184,272" fill="none" stroke="black"/>		<path d="M 256,64 L 336,64" fill="none" stroke="black"></path>
	<path d="M 232,288 L 312,288" fill="none" stroke="black"/>		<path d="M 40,96 L 72,96" fill="none" stroke="black"></path>
	<path d="M 40,320 L 88,320" fill="none" stroke="black"/>		<path d="M 128,96 L 176,96" fill="none" stroke="black"></path>
	<path d="M 104,320 L 160,320" fill="none" stroke="black"/>		<path d="M 264,96 L 304,96" fill="none" stroke="black"></path>
	<path d="M 232,320 L 288,320" fill="none" stroke="black"/>		<path d="M 88,112 L 104,112" fill="none" stroke="black"></path
	<path d="M 80,336 L 96,336" fill="none" stroke="black"/>		>
	<path d="M 176,336 L 232,336" fill="none" stroke="black"/>		<path d="M 192,112 L 240,112" fill="none" stroke="black"></pat
	<path d="M 304,336 L 336,336" fill="none" stroke="black"/>		h>
	<path d="M 392,336 L 480,336" fill="none" stroke="black"/>		<path d="M 320,112 L 360,112" fill="none" stroke="black"></pat
	<path d="M 40,352 L 88,352" fill="none" stroke="black"/>		h>
	<path d="M 104,352 L 160,352" fill="none" stroke="black"/>		<path d="M 40,128 L 72,128" fill="none" stroke="black"></path>
	<path d="M 232,352 L 288,352" fill="none" stroke="black"/>		<path d="M 128,128 L 176,128" fill="none" stroke="black"></pat
	<path d="M 40,368 L 88,368" fill="none" stroke="black"/>		h>
	<path d="M 104,368 L 160,368" fill="none" stroke="black"/>		<path d="M 264,128 L 304,128" fill="none" stroke="black"></pat
	<path d="M 232,368 L 288,368" fill="none" stroke="black"/>		h>
	<path d="M 352,368 L 376,368" fill="none" stroke="black"/>		<path d="M 40,144 L 72,144" fill="none" stroke="black"></path>
	<path d="M 80,384 L 96,384" fill="none" stroke="black"/>		<path d="M 128,144 L 176,144" fill="none" stroke="black"></pat
	<path d="M 176,384 L 232,384" fill="none" stroke="black"/>		h>
	<path d="M 304,384 L 336,384" fill="none" stroke="black"/>		<path d="M 264,144 L 304,144" fill="none" stroke="black"></pat
	<path d="M 384,384 L 480,384" fill="none" stroke="black"/>		h>
	<path d="M 40,400 L 88,400" fill="none" stroke="black"/>		<path d="M 88,160 L 104,160" fill="none" stroke="black"></path
	<path d="M 104,400 L 160,400" fill="none" stroke="black"/>		>
	<path d="M 232,400 L 288,400" fill="none" stroke="black"/>		<path d="M 192,160 L 240,160" fill="none" stroke="black"></pat
	<path d="M 40,416 L 88,416" fill="none" stroke="black"/>		h>
	<path d="M 104,416 L 160,416" fill="none" stroke="black"/>		<path d="M 320,160 L 360,160" fill="none" stroke="black"></pat
	<path d="M 232,416 L 288,416" fill="none" stroke="black"/>		h>
	<path d="M 80,432 L 96,432" fill="none" stroke="black"/>		<path d="M 40,176 L 72,176" fill="none" stroke="black"></path>
	<path d="M 176,432 L 232,432" fill="none" stroke="black"/>		<path d="M 128,176 L 176,176" fill="none" stroke="black"></pat
	<path d="M 304,432 L 352,432" fill="none" stroke="black"/>		h>
	<path d="M 40,448 L 88,448" fill="none" stroke="black"/>		<path d="M 264,176 L 304,176" fill="none" stroke="black"></pat
	<path d="M 104,448 L 160,448" fill="none" stroke="black"/>		h>
	<path d="M 232,448 L 288,448" fill="none" stroke="black"/>		<path d="M 40,192 L 72,192" fill="none" stroke="black"></path>
	<path d="M 8,464 L 184,464" fill="none" stroke="black"/>		<path d="M 128,192 L 176,192" fill="none" stroke="black"></pat
	<path d="M 216,464 L 296,464" fill="none" stroke="black"/>		h>
	<path d="M 200,480 L 512,480" fill="none" stroke="black"/>		<path d="M 264,192 L 304,192" fill="none" stroke="black"></pat
	<path d="M 232,64 C 223.16936,64 216,71.16936 216,80" fill="no		h>
	ne" stroke="black"/>		<path d="M 88,208 L 104,208" fill="none" stroke="black"></path
	<path d="M 40,96 C 31.16936,96 24,103.16936 24,112" fill="none		>
	" stroke="black"/>		<path d="M 192,208 L 240,208" fill="none" stroke="black"></pat
	<path d="M 160,96 C 168.83064,96 176,103.16936 176,112" fill="		h>
	none" stroke="black"/>		<path d="M 320,208 L 376,208" fill="none" stroke="black"></pat
	<path d="M 288,96 C 296.83064,96 304,103.16936 304,112" fill="		h>
	none" stroke="black"/>		<path d="M 416,208 L 504,208" fill="none" stroke="black"></pat
	<path d="M 40,128 C 31.16936,128 24,120.83064 24,112" fill="no		h>
	ne" stroke="black"/>		<path d="M 40,224 L 72,224" fill="none" stroke="black"></path>
	<path d="M 160,128 C 168.83064,128 176,120.83064 176,112" fill		<path d="M 128,224 L 176,224" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 288,128 C 296.83064,128 304,120.83064 304,112" fill		<path d="M 264,224 L 304,224" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 40,144 C 31.16936,144 24,151.16936 24,160" fill="no		<path d="M 8,240 L 208,240" fill="none" stroke="black"></path>
	ne" stroke="black"/>		<path d="M 240,240 L 320,240" fill="none" stroke="black"></pat
	<path d="M 160,144 C 168.83064,144 176,151.16936 176,160" fill		h>
	="none" stroke="black"/>		<path d="M 360,240 L 400,240" fill="none" stroke="black"></pat
	<path d="M 288,144 C 296.83064,144 304,151.16936 304,160" fill		h>
	="none" stroke="black"/>		<path d="M 408,256 L 504,256" fill="none" stroke="black"></pat
	<path d="M 40,176 C 31.16936,176 24,168.83064 24,160" fill="no		h>
	ne" stroke="black"/>		<path d="M 8,272 L 64,272" fill="none" stroke="black"></path>
	<path d="M 160,176 C 168.83064,176 176,168.83064 176,160" fill		<path d="M 120,272 L 208,272" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 288,176 C 296.83064,176 304,168.83064 304,160" fill		<path d="M 256,288 L 336,288" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 40,192 C 31.16936,192 24,199.16936 24,208" fill="no		<path d="M 40,320 L 72,320" fill="none" stroke="black"></path>
	ne" stroke="black"/>		<path d="M 128,320 L 176,320" fill="none" stroke="black"></pat
	<path d="M 160,192 C 168.83064,192 176,199.16936 176,208" fill		h>
	="none" stroke="black"/>		<path d="M 264,320 L 304,320" fill="none" stroke="black"></pat
	<path d="M 288,192 C 296.83064,192 304,199.16936 304,208" fill		h>
	="none" stroke="black"/>		<path d="M 88,336 L 104,336" fill="none" stroke="black"></path
	<path d="M 392,208 C 383.16936,208 376,215.16936 376,224" fill		>
	="none" stroke="black"/>		<path d="M 192,336 L 240,336" fill="none" stroke="black"></pat
	<path d="M 480,208 C 488.83064,208 496,215.16936 496,224" fill		h>
	="none" stroke="black"/>		<path d="M 320,336 L 360,336" fill="none" stroke="black"></pat
	<path d="M 40,224 C 31.16936,224 24,216.83064 24,208" fill="no		h>
	ne" stroke="black"/>		<path d="M 416,336 L 504,336" fill="none" stroke="black"></pat
	<path d="M 160,224 C 168.83064,224 176,216.83064 176,208" fill		h>
	="none" stroke="black"/>		<path d="M 40,352 L 72,352" fill="none" stroke="black"></path>
	<path d="M 288,224 C 296.83064,224 304,216.83064 304,208" fill		<path d="M 128,352 L 176,352" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 296,240 C 304.83064,240 312,232.83064 312,224" fill		<path d="M 264,352 L 304,352" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 480,256 C 488.83064,256 496,248.83064 496,240" fill		<path d="M 40,368 L 72,368" fill="none" stroke="black"></path>
	="none" stroke="black"/>		<path d="M 128,368 L 176,368" fill="none" stroke="black"></pat
	<path d="M 232,288 C 223.16936,288 216,295.16936 216,304" fill		h>
	="none" stroke="black"/>		<path d="M 264,368 L 312,368" fill="none" stroke="black"></pat
	<path d="M 40,320 C 31.16936,320 24,327.16936 24,336" fill="no		h>
	ne" stroke="black"/>		<path d="M 376,368 L 400,368" fill="none" stroke="black"></pat
	<path d="M 160,320 C 168.83064,320 176,327.16936 176,336" fill		h>
	="none" stroke="black"/>		<path d="M 88,384 L 104,384" fill="none" stroke="black"></path
	<path d="M 288,320 C 296.83064,320 304,327.16936 304,336" fill		>
	="none" stroke="black"/>		<path d="M 192,384 L 240,384" fill="none" stroke="black"></pat
	<path d="M 392,336 C 383.16936,336 376,343.16936 376,352" fill		h>
	="none" stroke="black"/>		<path d="M 328,384 L 360,384" fill="none" stroke="black"></pat
	<path d="M 480,336 C 488.83064,336 496,343.16936 496,352" fill		h>
	="none" stroke="black"/>		<path d="M 408,384 L 504,384" fill="none" stroke="black"></pat
	<path d="M 40,352 C 31.16936,352 24,344.83064 24,336" fill="no		h>
	ne" stroke="black"/>		<path d="M 40,400 L 72,400" fill="none" stroke="black"></path>
	<path d="M 160,352 C 168.83064,352 176,344.83064 176,336" fill		<path d="M 128,400 L 176,400" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 288,352 C 296.83064,352 304,344.83064 304,336" fill		<path d="M 264,400 L 312,400" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 40,368 C 31.16936,368 24,375.16936 24,384" fill="no		<path d="M 40,416 L 72,416" fill="none" stroke="black"></path>
	ne" stroke="black"/>		<path d="M 128,416 L 176,416" fill="none" stroke="black"></pat
	<path d="M 160,368 C 168.83064,368 176,375.16936 176,384" fill		h>
	="none" stroke="black"/>		<path d="M 264,416 L 312,416" fill="none" stroke="black"></pat
	<path d="M 288,368 C 296.83064,368 304,375.16936 304,384" fill		h>
	="none" stroke="black"/>		<path d="M 88,432 L 104,432" fill="none" stroke="black"></path
	<path d="M 480,384 C 488.83064,384 496,376.83064 496,368" fill		>
	="none" stroke="black"/>		<path d="M 192,432 L 240,432" fill="none" stroke="black"></pat
	<path d="M 40,400 C 31.16936,400 24,392.83064 24,384" fill="no		h>
	ne" stroke="black"/>		<path d="M 328,432 L 376,432" fill="none" stroke="black"></pat
	<path d="M 160,400 C 168.83064,400 176,392.83064 176,384" fill		h>
	="none" stroke="black"/>		<path d="M 40,448 L 72,448" fill="none" stroke="black"></path>
	<path d="M 288,400 C 296.83064,400 304,392.83064 304,384" fill		<path d="M 128,448 L 176,448" fill="none" stroke="black"></pat
	="none" stroke="black"/>		h>
	<path d="M 40,416 C 31.16936,416 24,423.16936 24,432" fill="no		<path d="M 264,448 L 312,448" fill="none" stroke="black"></pat
	ne" stroke="black"/>		h>
	<path d="M 160,416 C 168.83064,416 176,423.16936 176,432" fill		<path d="M 8,464 L 208,464" fill="none" stroke="black"></path>
	="none" stroke="black"/>		<path d="M 240,464 L 320,464" fill="none" stroke="black"></pat
	<path d="M 288,416 C 296.83064,416 304,423.16936 304,432" fill		h>
	="none" stroke="black"/>		<path d="M 224,480 L 536,480" fill="none" stroke="black"></pat
	<path d="M 40,448 C 31.16936,448 24,440.83064 24,432" fill="no		h>
	ne" stroke="black"/>		<path d="M 256,64 C 247.16936,64 240,71.16936 240,80" fill="no
	<path d="M 160,448 C 168.83064,448 176,440.83064 176,432" fill		ne" stroke="black"></path>
	="none" stroke="black"/>		<path d="M 40,96 C 31.16936,96 24,103.16936 24,112" fill="none
	<path d="M 288,448 C 296.83064,448 304,440.83064 304,432" fill		" stroke="black"></path>
	="none" stroke="black"/>		<path d="M 72,96 C 80.83064,96 88,103.16936 88,112" fill="none
	<path d="M 296,464 C 304.83064,464 312,456.83064 312,448" fill		" stroke="black"></path>
	="none" stroke="black"/>		<path d="M 128,96 C 119.16936,96 112,103.16936 112,112" fill="
	<polygon class="arrowhead" points="384,368 372,362.4 372,373.6		none" stroke="black"></path>
	" fill="black" transform="rotate(0,376,368)"/>		<path d="M 176,96 C 184.83064,96 192,103.16936 192,112" fill="
	<polygon class="arrowhead" points="384,240 372,234.4 372,245.6		none" stroke="black"></path>
	" fill="black" transform="rotate(0,376,240)"/>		<path d="M 264,96 C 255.16936,96 248,103.16936 248,112" fill="
	<path class="jump" d="M 352,248 C 358,248 358,232 352,232" fil		none" stroke="black"></path>
	l="none" stroke="black"/>		<path d="M 304,96 C 312.83064,96 320,103.16936 320,112" fill="
	<path class="jump" d="M 336,216 C 342,216 342,200 336,200" fil		none" stroke="black"></path>
	l="none" stroke="black"/>		<path d="M 40,128 C 31.16936,128 24,120.83064 24,112" fill="no
	<polygon class="arrowhead" points="240,432 228,426.4 228,437.6		ne" stroke="black"></path>
	" fill="black" transform="rotate(0,232,432)"/>		<path d="M 72,128 C 80.83064,128 88,120.83064 88,112" fill="no
	<polygon class="arrowhead" points="240,384 228,378.4 228,389.6		ne" stroke="black"></path>
	" fill="black" transform="rotate(0,232,384)"/>		<path d="M 128,128 C 119.16936,128 112,120.83064 112,112" fill
	<polygon class="arrowhead" points="240,336 228,330.4 228,341.6		="none" stroke="black"></path>
	" fill="black" transform="rotate(0,232,336)"/>		<path d="M 176,128 C 184.83064,128 192,120.83064 192,112" fill
	<polygon class="arrowhead" points="240,208 228,202.4 228,213.6		="none" stroke="black"></path>
	" fill="black" transform="rotate(0,232,208)"/>		<path d="M 264,128 C 255.16936,128 248,120.83064 248,112" fill
	<polygon class="arrowhead" points="240,160 228,154.4 228,165.6		="none" stroke="black"></path>
	" fill="black" transform="rotate(0,232,160)"/>		<path d="M 304,128 C 312.83064,128 320,120.83064 320,112" fill
	<polygon class="arrowhead" points="240,112 228,106.4 228,117.6		="none" stroke="black"></path>
	" fill="black" transform="rotate(0,232,112)"/>		<path d="M 40,144 C 31.16936,144 24,151.16936 24,160" fill="no
	<polygon class="arrowhead" points="104,432 92,426.4 92,437.6"		ne" stroke="black"></path>
	fill="black" transform="rotate(0,96,432)"/>		<path d="M 72,144 C 80.83064,144 88,151.16936 88,160" fill="no
	<polygon class="arrowhead" points="104,384 92,378.4 92,389.6"		ne" stroke="black"></path>
	fill="black" transform="rotate(0,96,384)"/>		<path d="M 128,144 C 119.16936,144 112,151.16936 112,160" fill
	<polygon class="arrowhead" points="104,336 92,330.4 92,341.6"		="none" stroke="black"></path>
	fill="black" transform="rotate(0,96,336)"/>		<path d="M 176,144 C 184.83064,144 192,151.16936 192,160" fill
	<polygon class="arrowhead" points="104,208 92,202.4 92,213.6"		="none" stroke="black"></path>
	fill="black" transform="rotate(0,96,208)"/>		<path d="M 264,144 C 255.16936,144 248,151.16936 248,160" fill
	<polygon class="arrowhead" points="104,160 92,154.4 92,165.6"		="none" stroke="black"></path>
	fill="black" transform="rotate(0,96,160)"/>		<path d="M 304,144 C 312.83064,144 320,151.16936 320,160" fill
	<polygon class="arrowhead" points="104,112 92,106.4 92,117.6"		="none" stroke="black"></path>
	fill="black" transform="rotate(0,96,112)"/>		<path d="M 40,176 C 31.16936,176 24,168.83064 24,160" fill="no
			ne" stroke="black"></path>
			<path d="M 72,176 C 80.83064,176 88,168.83064 88,160" fill="no
			ne" stroke="black"></path>
			<path d="M 128,176 C 119.16936,176 112,168.83064 112,160" fill
			="none" stroke="black"></path>
			<path d="M 176,176 C 184.83064,176 192,168.83064 192,160" fill
			="none" stroke="black"></path>
			<path d="M 264,176 C 255.16936,176 248,168.83064 248,160" fill
			="none" stroke="black"></path>
			<path d="M 304,176 C 312.83064,176 320,168.83064 320,160" fill
			="none" stroke="black"></path>
			<path d="M 40,192 C 31.16936,192 24,199.16936 24,208" fill="no
			ne" stroke="black"></path>
			<path d="M 72,192 C 80.83064,192 88,199.16936 88,208" fill="no
			ne" stroke="black"></path>
			<path d="M 128,192 C 119.16936,192 112,199.16936 112,208" fill
			="none" stroke="black"></path>
			<path d="M 176,192 C 184.83064,192 192,199.16936 192,208" fill
			="none" stroke="black"></path>
			<path d="M 264,192 C 255.16936,192 248,199.16936 248,208" fill
			="none" stroke="black"></path>
			<path d="M 304,192 C 312.83064,192 320,199.16936 320,208" fill
			="none" stroke="black"></path>
			<path d="M 416,208 C 407.16936,208 400,215.16936 400,224" fill
			="none" stroke="black"></path>
			<path d="M 504,208 C 512.83064,208 520,215.16936 520,224" fill
			="none" stroke="black"></path>
			<path d="M 40,224 C 31.16936,224 24,216.83064 24,208" fill="no
			ne" stroke="black"></path>
			<path d="M 72,224 C 80.83064,224 88,216.83064 88,208" fill="no
			ne" stroke="black"></path>
			<path d="M 128,224 C 119.16936,224 112,216.83064 112,208" fill
			="none" stroke="black"></path>
			<path d="M 176,224 C 184.83064,224 192,216.83064 192,208" fill
			="none" stroke="black"></path>
			<path d="M 264,224 C 255.16936,224 248,216.83064 248,208" fill
			="none" stroke="black"></path>
			<path d="M 304,224 C 312.83064,224 320,216.83064 320,208" fill
			="none" stroke="black"></path>
			<path d="M 320,240 C 328.83064,240 336,232.83064 336,224" fill
			="none" stroke="black"></path>
			<path d="M 504,256 C 512.83064,256 520,248.83064 520,240" fill
			="none" stroke="black"></path>
			<path d="M 256,288 C 247.16936,288 240,295.16936 240,304" fill
			="none" stroke="black"></path>
			<path d="M 40,320 C 31.16936,320 24,327.16936 24,336" fill="no
			ne" stroke="black"></path>
			<path d="M 72,320 C 80.83064,320 88,327.16936 88,336" fill="no
			ne" stroke="black"></path>
			<path d="M 128,320 C 119.16936,320 112,327.16936 112,336" fill
			="none" stroke="black"></path>
			<path d="M 176,320 C 184.83064,320 192,327.16936 192,336" fill
			="none" stroke="black"></path>
			<path d="M 264,320 C 255.16936,320 248,327.16936 248,336" fill
			="none" stroke="black"></path>
			<path d="M 304,320 C 312.83064,320 320,327.16936 320,336" fill
			="none" stroke="black"></path>
			<path d="M 416,336 C 407.16936,336 400,343.16936 400,352" fill
			="none" stroke="black"></path>
			<path d="M 504,336 C 512.83064,336 520,343.16936 520,352" fill
			="none" stroke="black"></path>
			<path d="M 40,352 C 31.16936,352 24,344.83064 24,336" fill="no
			ne" stroke="black"></path>
			<path d="M 72,352 C 80.83064,352 88,344.83064 88,336" fill="no
			ne" stroke="black"></path>
			<path d="M 128,352 C 119.16936,352 112,344.83064 112,336" fill
			="none" stroke="black"></path>
			<path d="M 176,352 C 184.83064,352 192,344.83064 192,336" fill
			="none" stroke="black"></path>
			<path d="M 264,352 C 255.16936,352 248,344.83064 248,336" fill
			="none" stroke="black"></path>
			<path d="M 304,352 C 312.83064,352 320,344.83064 320,336" fill
			="none" stroke="black"></path>
			<path d="M 40,368 C 31.16936,368 24,375.16936 24,384" fill="no
			ne" stroke="black"></path>
			<path d="M 72,368 C 80.83064,368 88,375.16936 88,384" fill="no
			ne" stroke="black"></path>
			<path d="M 128,368 C 119.16936,368 112,375.16936 112,384" fill
			="none" stroke="black"></path>
			<path d="M 176,368 C 184.83064,368 192,375.16936 192,384" fill
			="none" stroke="black"></path>
			<path d="M 264,368 C 255.16936,368 248,375.16936 248,384" fill
			="none" stroke="black"></path>
			<path d="M 312,368 C 320.83064,368 328,375.16936 328,384" fill
			="none" stroke="black"></path>
			<path d="M 504,384 C 512.83064,384 520,376.83064 520,368" fill
			="none" stroke="black"></path>
			<path d="M 40,400 C 31.16936,400 24,392.83064 24,384" fill="no
			ne" stroke="black"></path>
			<path d="M 72,400 C 80.83064,400 88,392.83064 88,384" fill="no
			ne" stroke="black"></path>
			<path d="M 128,400 C 119.16936,400 112,392.83064 112,384" fill
			="none" stroke="black"></path>
			<path d="M 176,400 C 184.83064,400 192,392.83064 192,384" fill
			="none" stroke="black"></path>
			<path d="M 264,400 C 255.16936,400 248,392.83064 248,384" fill
			="none" stroke="black"></path>
			<path d="M 312,400 C 320.83064,400 328,392.83064 328,384" fill
			="none" stroke="black"></path>
			<path d="M 40,416 C 31.16936,416 24,423.16936 24,432" fill="no
			ne" stroke="black"></path>
			<path d="M 72,416 C 80.83064,416 88,423.16936 88,432" fill="no
			ne" stroke="black"></path>
			<path d="M 128,416 C 119.16936,416 112,423.16936 112,432" fill
			="none" stroke="black"></path>
			<path d="M 176,416 C 184.83064,416 192,423.16936 192,432" fill
			="none" stroke="black"></path>
			<path d="M 264,416 C 255.16936,416 248,423.16936 248,432" fill
			="none" stroke="black"></path>
			<path d="M 312,416 C 320.83064,416 328,423.16936 328,432" fill
			="none" stroke="black"></path>
			<path d="M 40,448 C 31.16936,448 24,440.83064 24,432" fill="no
			ne" stroke="black"></path>
			<path d="M 72,448 C 80.83064,448 88,440.83064 88,432" fill="no
			ne" stroke="black"></path>
			<path d="M 128,448 C 119.16936,448 112,440.83064 112,432" fill
			="none" stroke="black"></path>
			<path d="M 176,448 C 184.83064,448 192,440.83064 192,432" fill
			="none" stroke="black"></path>
			<path d="M 264,448 C 255.16936,448 248,440.83064 248,432" fill
			="none" stroke="black"></path>
			<path d="M 312,448 C 320.83064,448 328,440.83064 328,432" fill
			="none" stroke="black"></path>
			<path d="M 320,464 C 328.83064,464 336,456.83064 336,448" fill
			="none" stroke="black"></path>
			<polygon class="arrowhead" points="408,368 396,362.4 396,373.6
			" fill="black" transform="rotate(0,400,368)"></polygon>
			<polygon class="arrowhead" points="408,240 396,234.4 396,245.6
			" fill="black" transform="rotate(0,400,240)"></polygon>
			<path class="jump" d="M 376,248 C 382,248 382,232 376,232" fil
			l="none" stroke="black"></path>
			<path class="jump" d="M 360,216 C 366,216 366,200 360,200" fil
			l="none" stroke="black"></path>
			<polygon class="arrowhead" points="248,432 236,426.4 236,437.6
			" fill="black" transform="rotate(0,240,432)"></polygon>
			<polygon class="arrowhead" points="248,384 236,378.4 236,389.6
			" fill="black" transform="rotate(0,240,384)"></polygon>
			<polygon class="arrowhead" points="248,336 236,330.4 236,341.6
			" fill="black" transform="rotate(0,240,336)"></polygon>
			<polygon class="arrowhead" points="248,208 236,202.4 236,213.6
			" fill="black" transform="rotate(0,240,208)"></polygon>
			<polygon class="arrowhead" points="248,160 236,154.4 236,165.6
			" fill="black" transform="rotate(0,240,160)"></polygon>
			<polygon class="arrowhead" points="248,112 236,106.4 236,117.6
			" fill="black" transform="rotate(0,240,112)"></polygon>
			<polygon class="arrowhead" points="112,432 100,426.4 100,437.6
			" fill="black" transform="rotate(0,104,432)"></polygon>
			<polygon class="arrowhead" points="112,384 100,378.4 100,389.6
			" fill="black" transform="rotate(0,104,384)"></polygon>
			<polygon class="arrowhead" points="112,336 100,330.4 100,341.6
			" fill="black" transform="rotate(0,104,336)"></polygon>
			<polygon class="arrowhead" points="112,208 100,202.4 100,213.6
			" fill="black" transform="rotate(0,104,208)"></polygon>
			<polygon class="arrowhead" points="112,160 100,154.4 100,165.6
			" fill="black" transform="rotate(0,104,160)"></polygon>
			<polygon class="arrowhead" points="112,112 100,106.4 100,117.6
			" fill="black" transform="rotate(0,104,112)"></polygon>
	<g class="text">		<g class="text">
	<text x="348" y="36">PE</text>		<text x="372" y="36">PE</text>
	<text x="84" y="52">NF-A</text>		<text x="84" y="52">NF-A</text>
	<text x="36" y="84">3GPP</text>		<text x="36" y="84">3GPP</text>
	<text x="88" y="84">S-NSSAI</text>		<text x="88" y="84">S-NSSAI</text>
	<text x="136" y="84">100</text>		<text x="136" y="84">100</text>
	<text x="256" y="84">SDP</text>		<text x="280" y="84">SDP</text>
	<text x="16" y="100">|</text>
	<text x="48" y="116">5QI=1</text>		<text x="48" y="116">5QI=1</text>
	<text x="128" y="116">DSCP=46</text>		<text x="152" y="116">DSCP=46</text>
	<text x="264" y="116">DSCP=46</text>		<text x="280" y="116">DSCP=46</text>
	<text x="52" y="164">5QI=65</text>		<text x="52" y="164">5QI=65</text>
	<text x="128" y="164">DSCP=46</text>		<text x="144" y="164">DSCP=46</text>
	<text x="264" y="164">DSCP=46</text>		<text x="280" y="164">DSCP=46</text>
	<text x="48" y="212">5QI=7</text>		<text x="48" y="212">5QI=7</text>
	<text x="128" y="212">DSCP=10</text>		<text x="144" y="212">DSCP=10</text>
	<text x="264" y="212">DSCP=10</text>		<text x="280" y="212">DSCP=10</text>
	<text x="388" y="228">TN</text>		<text x="412" y="228">TN</text>
	<text x="416" y="228">QoS</text>		<text x="440" y="228">QoS</text>
	<text x="456" y="228">Class</text>		<text x="480" y="228">Class</text>
	<text x="488" y="228">5</text>		<text x="512" y="228">5</text>
	<text x="424" y="244">Queue</text>		<text x="448" y="244">Queue</text>
	<text x="456" y="244">5</text>		<text x="480" y="244">5</text>
	<text x="92" y="276">NF-B</text>		<text x="92" y="276">NF-B</text>
	<text x="36" y="308">3GPP</text>		<text x="36" y="308">3GPP</text>
	<text x="88" y="308">S-NSSAI</text>		<text x="88" y="308">S-NSSAI</text>
	<text x="136" y="308">200</text>		<text x="136" y="308">200</text>
	<text x="256" y="308">SDP</text>		<text x="280" y="308">SDP</text>
	<text x="48" y="340">5QI=1</text>		<text x="48" y="340">5QI=1</text>
	<text x="128" y="340">DSCP=46</text>		<text x="152" y="340">DSCP=46</text>
	<text x="264" y="340">DSCP=46</text>		<text x="280" y="340">DSCP=46</text>
	<text x="388" y="356">TN</text>		<text x="412" y="356">TN</text>
	<text x="416" y="356">QoS</text>		<text x="440" y="356">QoS</text>
	<text x="456" y="356">Class</text>		<text x="480" y="356">Class</text>
	<text x="488" y="356">1</text>		<text x="512" y="356">1</text>
	<text x="424" y="372">Queue</text>		<text x="448" y="372">Queue</text>
	<text x="456" y="372">1</text>		<text x="480" y="372">1</text>
	<text x="52" y="388">5QI=65</text>		<text x="52" y="388">5QI=65</text>
	<text x="128" y="388">DSCP=46</text>		<text x="144" y="388">DSCP=46</text>
	<text x="264" y="388">DSCP=46</text>		<text x="280" y="388">DSCP=46</text>
	<text x="48" y="436">5QI=7</text>		<text x="48" y="436">5QI=7</text>
	<text x="128" y="436">DSCP=10</text>		<text x="144" y="436">DSCP=10</text>
	<text x="264" y="436">DSCP=10</text>		<text x="280" y="436">DSCP=10</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+--------------- PE -----------------+		+--------------- PE -----------------+
	+------ NF-A ---------+ | |		+------ NF-A ------------+ | |
	| | | .----------+ |		| | | .----------+ |
	| 3GPP S-NSSAI 100 | | | SDP | |		| 3GPP S-NSSAI 100 | | | SDP | |
	| .------. .-------. | | | .-------. | |		| .-----. .-------. | | | .------. | |
	| |5QI=1 +->DSCP=46 +------>DSCP=46 +---+ |		| |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ |
	| '------' '-------' | | | '-------' | | |		| '-----' '-------' | | | '------' | | |
	| .------. .-------. | | | .-------. | | |		| .-----. .-------. | | | .------. | | |
	| |5QI=65+->DSCP=46 +------>DSCP=46 +---+ |		| |5QI=65 +->+DSCP=46 +----->+DSCP=46 +----+ |
	| '------' '-------' | | | '-------' | | |		| '-----' '-------' | | | '------' | | |
	| .------. .-------. | | | .-------. | | |		| .-----. .-------. | | | .------. | | |
	| |5QI=7 +->DSCP=10 +------>DSCP=10 +---)-+ .------------. |		| |5QI=7 +->+DSCP=10 +----->+DSCP=10 +----)-+ .------------. |
	| '------' '-------' | | | '-------' | | | |TN QoS Class 5| |		| '-----' '-------' | | | '------' | | | |TN QoS Class 5| |
	+---------------------+ | '----------' +-)--> Queue 5 | |		+------------------------+ | '----------' +-)--> Queue 5 | |
	| | | '------------' |		| | | '------------' |
	+------- NF-B --------+ | | | |		+------- NF-B -----------+ | | | |
	| | | .----------+ | | |		| | | .----------+ | | |
	| 3GPP S-NSSAI 200 | | | SDP | | | |		| 3GPP S-NSSAI 200 | | | SDP | | | |
	| .------. .-------. | | | .-------. | | | |		| .-----. .-------. | | | .------. | | | |
	| |5QI=1 +->DSCP=46 +------>DSCP=46 +---+ | .------------. |		| |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ | .------------. |
	| '------' '-------' | | | '-------' | | | |TN QoS Class 1| |		| '-----' '-------' | | | '------' | | | |TN QoS Class 1| |
	| .------. .-------. | | | .-------. | | +--> Queue 1 | |		| .-----. .-------. | | | .-------. | | +--> Queue 1 | |
	| |5QI=65+->DSCP=46 +------>DSCP=46 +---+ | '------------' |		| |5QI=65 +->+DSCP=46 +----->+DSCP=46 +---+ | '------------' |
	| '------' '-------' | | | '-------' | | |		| '-----' '-------' | | | '-------' | | |
	| .------. .-------. | | | .-------. | | |		| .-----. .-------. | | | .-------. | | |
	| |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
	granular, fine-grained manner, with dedicated resource allocation for		<t>In the 5QI-aware model, compared to the 5QI-unaware model, provider networ
	each RFC 9543 Network Slice and dedicated resource allocation for number		k edge resources are controlled in an even more
	of traffic classes (most commonly up 4 or 8 traffic classes,		fine-grained manner, with dedicated resource allocation for
	depending on the Hardware capability of the equipment) within each RFC 9543		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>		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 Network Slice using multiple 5QIs can potentially specify ra tes in one 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 4962 ¶
	| 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 4876 ¶		skipping to change at line 5192 ¶
	'-' | | |		'-' | | |
	+--|---+ |		+--|---+ |
	+---------+		+---------+
	]]></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 5G 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		<artwork type="svg" align="center">
	/2000/svg" version="1.1" height="656" width="552" viewBox="0 0 552 656" class="d		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="656" width="552" v
	iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin		iewBox="0 0 552 656" class="diagram" text-anchor="middle" font-family="monospace
	ecap="round">		" font-size="13px" stroke-linecap="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
	<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 80,48 L 80,624" fill="none" stroke="black"></path
	<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 112,32 L 112,48" fill="none" stroke="black"></pat
	<path d="M 144,240 L 144,272" fill="none" stroke="black"/>		h>
	<path d="M 144,312 L 144,376" fill="none" stroke="black"/>		<path d="M 112,624 L 112,640" fill="none" stroke="black"></p
	<path d="M 144,432 L 144,456" fill="none" stroke="black"/>		ath>
	<path d="M 144,504 L 144,568" fill="none" stroke="black"/>		<path d="M 144,48 L 144,64" fill="none" stroke="black"></pat
	<path d="M 384,56 L 384,248" fill="none" stroke="black"/>		h>
	<path d="M 384,264 L 384,320" fill="none" stroke="black"/>		<path d="M 144,240 L 144,272" fill="none" stroke="black"></p
	<path d="M 384,352 L 384,424" fill="none" stroke="black"/>		ath>
	<path d="M 384,440 L 384,592" fill="none" stroke="black"/>		<path d="M 144,312 L 144,376" fill="none" stroke="black"></p
	<path d="M 32,32 L 112,32" fill="none" stroke="black"/>		ath>
	<path d="M 80,48 L 104,48" fill="none" stroke="black"/>		<path d="M 144,432 L 144,456" fill="none" stroke="black"></p
	<path d="M 120,48 L 144,48" fill="none" stroke="black"/>		ath>
	<path d="M 128,64 L 136,64" fill="none" stroke="black"/>		<path d="M 144,504 L 144,568" fill="none" stroke="black"></p
	<path d="M 152,64 L 352,64" fill="none" stroke="black"/>		ath>
	<path d="M 8,80 L 24,80" fill="none" stroke="black"/>		<path d="M 384,56 L 384,248" fill="none" stroke="black"></pa
	<path d="M 40,80 L 72,80" fill="none" stroke="black"/>		th>
	<path d="M 88,80 L 104,80" fill="none" stroke="black"/>		<path d="M 384,264 L 384,320" fill="none" stroke="black"></p
	<path d="M 120,80 L 136,80" fill="none" stroke="black"/>		ath>
	<path d="M 128,96 L 352,96" fill="none" stroke="black"/>		<path d="M 384,352 L 384,424" fill="none" stroke="black"></p
	<path d="M 128,112 L 352,112" fill="none" stroke="black"/>		ath>
	<path d="M 8,128 L 24,128" fill="none" stroke="black"/>		<path d="M 384,440 L 384,616" fill="none" stroke="black"></p
	<path d="M 40,128 L 72,128" fill="none" stroke="black"/>		ath>
	<path d="M 120,128 L 136,128" fill="none" stroke="black"/>		<path d="M 32,32 L 112,32" fill="none" stroke="black"></path
	<path d="M 128,144 L 352,144" fill="none" stroke="black"/>		>
	<path d="M 128,160 L 352,160" fill="none" stroke="black"/>		<path d="M 80,48 L 104,48" fill="none" stroke="black"></path
	<path d="M 8,176 L 24,176" fill="none" stroke="black"/>		>
	<path d="M 40,176 L 72,176" fill="none" stroke="black"/>		<path d="M 120,48 L 144,48" fill="none" stroke="black"></pat
	<path d="M 88,176 L 104,176" fill="none" stroke="black"/>		h>
	<path d="M 120,176 L 136,176" fill="none" stroke="black"/>		<path d="M 128,64 L 136,64" fill="none" stroke="black"></pat
	<path d="M 128,192 L 352,192" fill="none" stroke="black"/>		h>
	<path d="M 128,208 L 352,208" fill="none" stroke="black"/>		<path d="M 152,64 L 352,64" fill="none" stroke="black"></pat
	<path d="M 8,224 L 24,224" fill="none" stroke="black"/>		h>
	<path d="M 40,224 L 72,224" fill="none" stroke="black"/>		<path d="M 8,80 L 24,80" fill="none" stroke="black"></path>
	<path d="M 88,224 L 104,224" fill="none" stroke="black"/>		<path d="M 40,80 L 72,80" fill="none" stroke="black"></path>
	<path d="M 120,224 L 136,224" fill="none" stroke="black"/>		<path d="M 88,80 L 104,80" fill="none" stroke="black"></path
	<path d="M 128,240 L 136,240" fill="none" stroke="black"/>		>
	<path d="M 152,240 L 352,240" fill="none" stroke="black"/>		<path d="M 120,80 L 136,80" fill="none" stroke="black"></pat
	<path d="M 80,256 L 144,256" fill="none" stroke="black"/>		h>
	<path d="M 128,272 L 136,272" fill="none" stroke="black"/>		<path d="M 128,96 L 352,96" fill="none" stroke="black"></pat
	<path d="M 152,272 L 352,272" fill="none" stroke="black"/>		h>
	<path d="M 128,304 L 352,304" fill="none" stroke="black"/>		<path d="M 128,112 L 352,112" fill="none" stroke="black"></p
	<path d="M 128,384 L 352,384" fill="none" stroke="black"/>		ath>
	<path d="M 128,416 L 352,416" fill="none" stroke="black"/>		<path d="M 8,128 L 24,128" fill="none" stroke="black"></path
	<path d="M 80,432 L 144,432" fill="none" stroke="black"/>		>
	<path d="M 128,464 L 352,464" fill="none" stroke="black"/>		<path d="M 40,128 L 72,128" fill="none" stroke="black"></pat
	<path d="M 128,496 L 352,496" fill="none" stroke="black"/>		h>
	<path d="M 128,576 L 352,576" fill="none" stroke="black"/>		<path d="M 120,128 L 136,128" fill="none" stroke="black"></p
	<path d="M 128,608 L 352,608" fill="none" stroke="black"/>		ath>
	<path d="M 80,624 L 104,624" fill="none" stroke="black"/>		<path d="M 128,144 L 352,144" fill="none" stroke="black"></p
	<path d="M 120,624 L 144,624" fill="none" stroke="black"/>		ath>
	<path d="M 32,640 L 112,640" fill="none" stroke="black"/>		<path d="M 128,160 L 352,160" fill="none" stroke="black"></p
	<path d="M 128,64 C 119.16936,64 112,71.16936 112,80" fill="		ath>
	none" stroke="black"/>		<path d="M 8,176 L 24,176" fill="none" stroke="black"></path
	<path d="M 352,64 C 360.83064,64 368,71.16936 368,80" fill="		>
	none" stroke="black"/>		<path d="M 40,176 L 72,176" fill="none" stroke="black"></pat
	<path d="M 128,96 C 119.16936,96 112,88.83064 112,80" fill="		h>
	none" stroke="black"/>		<path d="M 88,176 L 104,176" fill="none" stroke="black"></pa
	<path d="M 352,96 C 360.83064,96 368,88.83064 368,80" fill="		th>
	none" stroke="black"/>		<path d="M 120,176 L 136,176" fill="none" stroke="black"></p
	<path d="M 128,112 C 119.16936,112 112,119.16936 112,128" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,192 L 352,192" fill="none" stroke="black"></p
	<path d="M 352,112 C 360.83064,112 368,119.16936 368,128" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,208 L 352,208" fill="none" stroke="black"></p
	<path d="M 128,144 C 119.16936,144 112,136.83064 112,128" fi		ath>
	ll="none" stroke="black"/>		<path d="M 8,224 L 24,224" fill="none" stroke="black"></path
	<path d="M 352,144 C 360.83064,144 368,136.83064 368,128" fi		>
	ll="none" stroke="black"/>		<path d="M 40,224 L 72,224" fill="none" stroke="black"></pat
	<path d="M 128,160 C 119.16936,160 112,167.16936 112,176" fi		h>
	ll="none" stroke="black"/>		<path d="M 88,224 L 104,224" fill="none" stroke="black"></pa
	<path d="M 352,160 C 360.83064,160 368,167.16936 368,176" fi		th>
	ll="none" stroke="black"/>		<path d="M 120,224 L 136,224" fill="none" stroke="black"></p
	<path d="M 128,192 C 119.16936,192 112,184.83064 112,176" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,240 L 136,240" fill="none" stroke="black"></p
	<path d="M 352,192 C 360.83064,192 368,184.83064 368,176" fi		ath>
	ll="none" stroke="black"/>		<path d="M 152,240 L 352,240" fill="none" stroke="black"></p
	<path d="M 128,208 C 119.16936,208 112,215.16936 112,224" fi		ath>
	ll="none" stroke="black"/>		<path d="M 80,256 L 144,256" fill="none" stroke="black"></pa
	<path d="M 352,208 C 360.83064,208 368,215.16936 368,224" fi		th>
	ll="none" stroke="black"/>		<path d="M 128,272 L 136,272" fill="none" stroke="black"></p
	<path d="M 128,240 C 119.16936,240 112,232.83064 112,224" fi		ath>
	ll="none" stroke="black"/>		<path d="M 152,272 L 352,272" fill="none" stroke="black"></p
	<path d="M 352,240 C 360.83064,240 368,232.83064 368,224" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,304 L 352,304" fill="none" stroke="black"></p
	<path d="M 128,272 C 119.16936,272 112,279.16936 112,288" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,384 L 352,384" fill="none" stroke="black"></p
	<path d="M 352,272 C 360.83064,272 368,279.16936 368,288" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,416 L 352,416" fill="none" stroke="black"></p
	<path d="M 128,304 C 119.16936,304 112,296.83064 112,288" fi		ath>
	ll="none" stroke="black"/>		<path d="M 80,432 L 144,432" fill="none" stroke="black"></pa
	<path d="M 352,304 C 360.83064,304 368,296.83064 368,288" fi		th>
	ll="none" stroke="black"/>		<path d="M 128,464 L 352,464" fill="none" stroke="black"></p
	<path d="M 128,384 C 119.16936,384 112,391.16936 112,400" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,496 L 352,496" fill="none" stroke="black"></p
	<path d="M 352,384 C 360.83064,384 368,391.16936 368,400" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,576 L 352,576" fill="none" stroke="black"></p
	<path d="M 128,416 C 119.16936,416 112,408.83064 112,400" fi		ath>
	ll="none" stroke="black"/>		<path d="M 128,608 L 352,608" fill="none" stroke="black"></p
	<path d="M 352,416 C 360.83064,416 368,408.83064 368,400" fi		ath>
	ll="none" stroke="black"/>		<path d="M 80,624 L 104,624" fill="none" stroke="black"></pa
	<path d="M 128,464 C 119.16936,464 112,471.16936 112,480" fi		th>
	ll="none" stroke="black"/>		<path d="M 120,624 L 144,624" fill="none" stroke="black"></p
	<path d="M 352,464 C 360.83064,464 368,471.16936 368,480" fi		ath>
	ll="none" stroke="black"/>		<path d="M 32,640 L 112,640" fill="none" stroke="black"></pa
	<path d="M 128,496 C 119.16936,496 112,488.83064 112,480" fi		th>
	ll="none" stroke="black"/>		<path d="M 128,64 C 119.16936,64 112,71.16936 112,80" fill="
	<path d="M 352,496 C 360.83064,496 368,488.83064 368,480" fi		none" stroke="black"></path>
	ll="none" stroke="black"/>		<path d="M 352,64 C 360.83064,64 368,71.16936 368,80" fill="
	<path d="M 128,576 C 119.16936,576 112,583.16936 112,592" fi		none" stroke="black"></path>
	ll="none" stroke="black"/>		<path d="M 128,96 C 119.16936,96 112,88.83064 112,80" fill="
	<path d="M 352,576 C 360.83064,576 368,583.16936 368,592" fi		none" stroke="black"></path>
	ll="none" stroke="black"/>		<path d="M 352,96 C 360.83064,96 368,88.83064 368,80" fill="
	<path d="M 128,608 C 119.16936,608 112,600.83064 112,592" fi		none" stroke="black"></path>
	ll="none" stroke="black"/>		<path d="M 128,112 C 119.16936,112 112,119.16936 112,128" fi
	<path d="M 352,608 C 360.83064,608 368,600.83064 368,592" fi		ll="none" stroke="black"></path>
	ll="none" stroke="black"/>		<path d="M 352,112 C 360.83064,112 368,119.16936 368,128" fi
	<polygon class="arrowhead" points="144,224 132,218.4 132,229		ll="none" stroke="black"></path>
	.6" fill="black" transform="rotate(0,136,224)"/>		<path d="M 128,144 C 119.16936,144 112,136.83064 112,128" fi
	<polygon class="arrowhead" points="144,176 132,170.4 132,181		ll="none" stroke="black"></path>
	.6" fill="black" transform="rotate(0,136,176)"/>		<path d="M 352,144 C 360.83064,144 368,136.83064 368,128" fi
	<polygon class="arrowhead" points="144,128 132,122.4 132,133		ll="none" stroke="black"></path>
	.6" fill="black" transform="rotate(0,136,128)"/>		<path d="M 128,160 C 119.16936,160 112,167.16936 112,176" fi
	<polygon class="arrowhead" points="144,80 132,74.4 132,85.6"		ll="none" stroke="black"></path>
	fill="black" transform="rotate(0,136,80)"/>		<path d="M 352,160 C 360.83064,160 368,167.16936 368,176" fi
			ll="none" stroke="black"></path>
			<path d="M 128,192 C 119.16936,192 112,184.83064 112,176" fi
			ll="none" stroke="black"></path>
			<path d="M 352,192 C 360.83064,192 368,184.83064 368,176" fi
			ll="none" stroke="black"></path>
			<path d="M 128,208 C 119.16936,208 112,215.16936 112,224" fi
			ll="none" stroke="black"></path>
			<path d="M 352,208 C 360.83064,208 368,215.16936 368,224" fi
			ll="none" stroke="black"></path>
			<path d="M 128,240 C 119.16936,240 112,232.83064 112,224" fi
			ll="none" stroke="black"></path>
			<path d="M 352,240 C 360.83064,240 368,232.83064 368,224" fi
			ll="none" stroke="black"></path>
			<path d="M 128,272 C 119.16936,272 112,279.16936 112,288" fi
			ll="none" stroke="black"></path>
			<path d="M 352,272 C 360.83064,272 368,279.16936 368,288" fi
			ll="none" stroke="black"></path>
			<path d="M 128,304 C 119.16936,304 112,296.83064 112,288" fi
			ll="none" stroke="black"></path>
			<path d="M 352,304 C 360.83064,304 368,296.83064 368,288" fi
			ll="none" stroke="black"></path>
			<path d="M 128,384 C 119.16936,384 112,391.16936 112,400" fi
			ll="none" stroke="black"></path>
			<path d="M 352,384 C 360.83064,384 368,391.16936 368,400" fi
			ll="none" stroke="black"></path>
			<path d="M 128,416 C 119.16936,416 112,408.83064 112,400" fi
			ll="none" stroke="black"></path>
			<path d="M 352,416 C 360.83064,416 368,408.83064 368,400" fi
			ll="none" stroke="black"></path>
			<path d="M 128,464 C 119.16936,464 112,471.16936 112,480" fi
			ll="none" stroke="black"></path>
			<path d="M 352,464 C 360.83064,464 368,471.16936 368,480" fi
			ll="none" stroke="black"></path>
			<path d="M 128,496 C 119.16936,496 112,488.83064 112,480" fi
			ll="none" stroke="black"></path>
			<path d="M 352,496 C 360.83064,496 368,488.83064 368,480" fi
			ll="none" stroke="black"></path>
			<path d="M 128,576 C 119.16936,576 112,583.16936 112,592" fi
			ll="none" stroke="black"></path>
			<path d="M 352,576 C 360.83064,576 368,583.16936 368,592" fi
			ll="none" stroke="black"></path>
			<path d="M 128,608 C 119.16936,608 112,600.83064 112,592" fi
			ll="none" stroke="black"></path>
			<path d="M 352,608 C 360.83064,608 368,600.83064 368,592" fi
			ll="none" stroke="black"></path>
			<polygon class="arrowhead" points="144,224 132,218.4 132,229
			.6" fill="black" transform="rotate(0,136,224)"></polygon>
			<polygon class="arrowhead" points="144,176 132,170.4 132,181
			.6" fill="black" transform="rotate(0,136,176)"></polygon>
			<polygon class="arrowhead" points="144,128 132,122.4 132,133
			.6" fill="black" transform="rotate(0,136,128)"></polygon>
			<polygon class="arrowhead" points="144,80 132,74.4 132,85.6"
			fill="black" transform="rotate(0,136,80)"></polygon>
	<g class="text">		<g class="text">
	<text x="192" y="36">QoS</text>		<text x="192" y="36">QoS</text>
	<text x="236" y="36">output</text>		<text x="236" y="36">output</text>
	<text x="292" y="36">queues</text>		<text x="292" y="36">queues</text>
	<text x="160" y="52">-</text>		<text x="160" y="52">-</text>
	<text x="176" y="52">-</text>		<text x="176" y="52">-</text>
	<text x="192" y="52">-</text>		<text x="192" y="52">-</text>
	<text x="208" y="52">-</text>		<text x="208" y="52">-</text>
	<text x="224" y="52">-</text>		<text x="224" y="52">-</text>
	<text x="240" y="52">-</text>		<text x="240" y="52">-</text>
	skipping to change at line 5063 ¶		skipping to change at line 5380 ¶
	<text x="376" y="276">\</text>		<text x="376" y="276">\</text>
	<text x="392" y="276">/</text>		<text x="392" y="276">/</text>
	<text x="56" y="292">t</text>		<text x="56" y="292">t</text>
	<text x="56" y="308">a</text>		<text x="56" y="308">a</text>
	<text x="56" y="324">c</text>		<text x="56" y="324">c</text>
	<text x="96" y="324">S</text>		<text x="96" y="324">S</text>
	<text x="56" y="340">h</text>		<text x="56" y="340">h</text>
	<text x="96" y="340">l</text>		<text x="96" y="340">l</text>
	<text x="56" y="356">m</text>		<text x="56" y="356">m</text>
	<text x="96" y="356">i</text>		<text x="96" y="356">i</text>
	<text x="156" y="356">..</text>		<text x="232" y="356">...</text>
	<text x="476" y="356">weight-Slice-2-CIR</text>		<text x="476" y="356">weight-Slice-2-CIR</text>
	<text x="56" y="372">e</text>		<text x="56" y="372">e</text>
	<text x="96" y="372">c</text>		<text x="96" y="372">c</text>
	<text x="472" y="372">shaping-Slice-2-PIR</text>		<text x="472" y="372">shaping-Slice-2-PIR</text>
	<text x="56" y="388">n</text>		<text x="56" y="388">n</text>
	<text x="96" y="388">e</text>		<text x="96" y="388">e</text>
	<text x="56" y="404">t</text>		<text x="56" y="404">t</text>
	<text x="96" y="420">2</text>		<text x="96" y="420">2</text>
	<text x="376" y="420">/</text>		<text x="376" y="420">/</text>
	<text x="392" y="420">\</text>		<text x="392" y="420">\</text>
	skipping to change at line 5111 ¶		skipping to change at line 5428 ¶
	<text x="376" y="452">\</text>		<text x="376" y="452">\</text>
	<text x="392" y="452">/</text>		<text x="392" y="452">/</text>
	<text x="56" y="468">r</text>		<text x="56" y="468">r</text>
	<text x="56" y="484">c</text>		<text x="56" y="484">c</text>
	<text x="56" y="500">u</text>		<text x="56" y="500">u</text>
	<text x="56" y="516">i</text>		<text x="56" y="516">i</text>
	<text x="96" y="516">S</text>		<text x="96" y="516">S</text>
	<text x="56" y="532">t</text>		<text x="56" y="532">t</text>
	<text x="96" y="532">l</text>		<text x="96" y="532">l</text>
	<text x="96" y="548">i</text>		<text x="96" y="548">i</text>
	<text x="156" y="548">..</text>		<text x="232" y="548">...</text>
	<text x="476" y="548">weight-Slice-3-CIR</text>		<text x="476" y="548">weight-Slice-3-CIR</text>
	<text x="96" y="564">c</text>		<text x="96" y="564">c</text>
	<text x="472" y="564">shaping-Slice-3-PIR</text>		<text x="472" y="564">shaping-Slice-3-PIR</text>
	<text x="96" y="580">e</text>		<text x="96" y="580">e</text>
	<text x="96" y="612">3</text>		<text x="96" y="612">3</text>
	<text x="392" y="612">/|\</text>		<text x="376" y="612">/</text>
			<text x="392" y="612">\</text>
	<text x="160" y="628">-</text>		<text x="160" y="628">-</text>
	<text x="176" y="628">-</text>		<text x="176" y="628">-</text>
	<text x="192" y="628">-</text>		<text x="192" y="628">-</text>
	<text x="208" y="628">-</text>		<text x="208" y="628">-</text>
	<text x="224" y="628">-</text>		<text x="224" y="628">-</text>
	<text x="240" y="628">-</text>		<text x="240" y="628">-</text>
	<text x="256" y="628">-</text>		<text x="256" y="628">-</text>
	<text x="272" y="628">-</text>		<text x="272" y="628">-</text>
	<text x="288" y="628">-</text>		<text x="288" y="628">-</text>
	<text x="304" y="628">-</text>		<text x="304" y="628">-</text>
	skipping to change at line 5167 ¶		skipping to change at line 5486 ¶
	| | 1 '-----------------------------' |		| | 1 '-----------------------------' |
	| | .-----------------------------. |		| | .-----------------------------. |
	---|-----|---|--> Best Effort (remainder) | |		---|-----|---|--> Best Effort (remainder) | |
	| | '--|--------------------------' /|\		| | '--|--------------------------' /|\
	| A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -		| A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
	| t | .--|--------------------------. \|/		| t | .--|--------------------------. \|/
	| t | | | |		| t | | | |
	| a | '-----------------------------' |		| a | '-----------------------------' |
	| c | S | |		| c | S | |
	| h | l |		| h | l |
	| m | i ... | weight-Slice-2-CIR		| m | i | ... | weight-Slice-2-CIR
	| e | c | | shaping-Slice-2-PIR		| e | c | | shaping-Slice-2-PIR
	| n | e .-----------------------------. |		| n | e .-----------------------------. |
	| t | | | |		| t | | | |
	| | 2 '-----------------------------' /|\		| | 2 '-----------------------------' /|\
	| C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -		| C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
	| i | | \|/		| i | | \|/
	| r + .-----------------------------. |		| r + .-----------------------------. |
	| c | | | |		| c | | | |
	| u | '-----------------------------' |		| u | '-----------------------------' |
	| i | S | |		| i | S | |
	| t | l | |		| t | l | |
	| | i ... | weight-Slice-3-CIR		| | i | ... | weight-Slice-3-CIR
	| | c | | shaping-Slice-3-PIR		| | c | | shaping-Slice-3-PIR
	| | e .-----------------------------. |		| | e .-----------------------------. |
	| | | | |		| | | | |
	| | 3 '-----------------------------' /|\		| | 3 '-----------------------------' /|\
	| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -		| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
	+---------+		+---------+
	]]></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		<t>Transit resource control is much simpler than edge resource control i
	n the provider network.		n the provider network.
	As outlined in <xref target="_figure-QoS-5QI-aware"/>, at the provider networ		As outlined in <xref target="_figure-QoS-5QI-aware"/>, at the provider networ
	k edge, 5Q QoS Class marking		k edge, 5G 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>
	<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		<t>Also, underlay transports may be realized using separate NRPs. However,
	logy (2024).</t>		such an approach is left out of the scope given the current state of the techno
			logy at the time of writing this document.</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 5722 ¶
	| | 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 5953 ¶
	: | | 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 6240 ¶
	</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		<artwork type="svg" align="center">
	0/svg" version="1.1" height="464" width="576" viewBox="0 0 576 464" class="diagr		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="568" v
	am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap		iewBox="0 0 568 480" class="diagram" text-anchor="middle" font-family="monospace
	="round">		" 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>
	<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>
	<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>
	<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>
	<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>
	<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>
	<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>
	<path d="M 176,32 L 176,208" fill="none" stroke="black"/>		<path d="M 176,32 L 176,208" fill="none" stroke="black"></path>
	<path d="M 200,64 L 200,96" fill="none" stroke="black"/>		<path d="M 200,64 L 200,96" fill="none" stroke="black"></path>
	<path d="M 200,160 L 200,192" fill="none" stroke="black"/>		<path d="M 200,160 L 200,192" fill="none" stroke="black"></path>
	<path d="M 208,32 L 208,56" fill="none" stroke="black"/>		<path d="M 208,32 L 208,56" fill="none" stroke="black"></path>
	<path d="M 208,104 L 208,152" fill="none" stroke="black"/>		<path d="M 208,104 L 208,152" fill="none" stroke="black"></path>
	<path d="M 208,200 L 208,416" fill="none" stroke="black"/>		<path d="M 208,200 L 208,416" fill="none" stroke="black"></path>
	<path d="M 240,64 L 240,96" fill="none" stroke="black"/>		<path d="M 248,64 L 248,96" fill="none" stroke="black"></path>
	<path d="M 240,160 L 240,192" fill="none" stroke="black"/>		<path d="M 248,160 L 248,192" fill="none" stroke="black"></path>
	<path d="M 320,64 L 320,96" fill="none" stroke="black"/>		<path d="M 312,64 L 312,96" fill="none" stroke="black"></path>
	<path d="M 320,160 L 320,192" fill="none" stroke="black"/>		<path d="M 312,160 L 312,192" fill="none" stroke="black"></path>
	<path d="M 320,256 L 320,288" fill="none" stroke="black"/>		<path d="M 312,256 L 312,288" fill="none" stroke="black"></path>
	<path d="M 320,352 L 320,384" fill="none" stroke="black"/>		<path d="M 312,352 L 312,384" fill="none" stroke="black"></path>
	<path d="M 352,32 L 352,56" fill="none" stroke="black"/>		<path d="M 352,32 L 352,56" fill="none" stroke="black"></path>
	<path d="M 352,104 L 352,152" fill="none" stroke="black"/>		<path d="M 352,104 L 352,152" fill="none" stroke="black"></path>
	<path d="M 352,200 L 352,248" fill="none" stroke="black"/>		<path d="M 352,200 L 352,248" fill="none" stroke="black"></path>
	<path d="M 352,296 L 352,344" fill="none" stroke="black"/>		<path d="M 352,296 L 352,344" fill="none" stroke="black"></path>
	<path d="M 352,392 L 352,416" fill="none" stroke="black"/>		<path d="M 352,392 L 352,416" fill="none" stroke="black"></path>
	<path d="M 360,64 L 360,96" fill="none" stroke="black"/>		<path d="M 360,64 L 360,96" fill="none" stroke="black"></path>
	<path d="M 360,160 L 360,192" fill="none" stroke="black"/>		<path d="M 360,160 L 360,192" fill="none" stroke="black"></path>
	<path d="M 360,256 L 360,288" fill="none" stroke="black"/>		<path d="M 360,256 L 360,288" fill="none" stroke="black"></path>
	<path d="M 360,352 L 360,384" fill="none" stroke="black"/>		<path d="M 360,352 L 360,384" fill="none" stroke="black"></path>
	<path d="M 384,32 L 384,208" fill="none" stroke="black"/>		<path d="M 384,32 L 384,208" fill="none" stroke="black"></path>
	<path d="M 384,240 L 384,416" fill="none" stroke="black"/>		<path d="M 384,240 L 384,416" fill="none" stroke="black"></path>
	<path d="M 416,64 L 416,96" fill="none" stroke="black"/>		<path d="M 416,64 L 416,96" fill="none" stroke="black"></path>
	<path d="M 416,256 L 416,288" fill="none" stroke="black"/>		<path d="M 416,256 L 416,288" fill="none" stroke="black"></path>
	<path d="M 440,112 L 440,144" fill="none" stroke="black"/>		<path d="M 440,112 L 440,144" fill="none" stroke="black"></path>
	<path d="M 448,304 L 448,336" fill="none" stroke="black"/>		<path d="M 448,304 L 448,336" fill="none" stroke="black"></path>
	<path d="M 472,64 L 472,96" fill="none" stroke="black"/>		<path d="M 472,64 L 472,96" fill="none" stroke="black"></path>
	<path d="M 472,256 L 472,288" fill="none" stroke="black"/>		<path d="M 472,256 L 472,288" fill="none" stroke="black"></path>
	<path d="M 480,160 L 480,192" fill="none" stroke="black"/>		<path d="M 480,160 L 480,192" fill="none" stroke="black"></path>
	<path d="M 480,352 L 480,384" fill="none" stroke="black"/>		<path d="M 480,352 L 480,384" fill="none" stroke="black"></path>
	<path d="M 496,112 L 496,144" fill="none" stroke="black"/>		<path d="M 496,112 L 496,144" fill="none" stroke="black"></path>
	<path d="M 504,304 L 504,336" fill="none" stroke="black"/>		<path d="M 504,304 L 504,336" fill="none" stroke="black"></path>
	<path d="M 536,160 L 536,192" fill="none" stroke="black"/>		<path d="M 536,160 L 536,192" fill="none" stroke="black"></path>
	<path d="M 536,352 L 536,384" fill="none" stroke="black"/>		<path d="M 536,352 L 536,384" fill="none" stroke="black"></path>
	<path d="M 552,32 L 552,208" fill="none" stroke="black"/>		<path d="M 552,32 L 552,208" fill="none" stroke="black"></path>
	<path d="M 552,240 L 552,416" fill="none" stroke="black"/>		<path d="M 552,240 L 552,416" fill="none" stroke="black"></path>
	<path d="M 8,32 L 72,32" fill="none" stroke="black"/>		<path d="M 8,32 L 72,32" fill="none" stroke="black"></path>
	<path d="M 120,32 L 176,32" fill="none" stroke="black"/>		<path d="M 120,32 L 176,32" fill="none" stroke="black"></path>
	<path d="M 208,32 L 352,32" fill="none" stroke="black"/>		<path d="M 208,32 L 352,32" fill="none" stroke="black"></path>
	<path d="M 384,32 L 448,32" fill="none" stroke="black"/>		<path d="M 384,32 L 448,32" fill="none" stroke="black"></path>
	<path d="M 496,32 L 552,32" fill="none" stroke="black"/>		<path d="M 496,32 L 552,32" fill="none" stroke="black"></path>
	<path d="M 24,64 L 80,64" fill="none" stroke="black"/>		<path d="M 24,64 L 80,64" fill="none" stroke="black"></path>
	<path d="M 200,64 L 240,64" fill="none" stroke="black"/>		<path d="M 200,64 L 248,64" fill="none" stroke="black"></path>
	<path d="M 320,64 L 360,64" fill="none" stroke="black"/>		<path d="M 312,64 L 360,64" fill="none" stroke="black"></path>
	<path d="M 416,64 L 472,64" fill="none" stroke="black"/>		<path d="M 416,64 L 472,64" fill="none" stroke="black"></path>
	<path d="M 176,80 L 192,80" fill="none" stroke="black"/>		<path d="M 176,80 L 192,80" fill="none" stroke="black"></path>
	<path d="M 368,80 L 384,80" fill="none" stroke="black"/>		<path d="M 368,80 L 384,80" fill="none" stroke="black"></path>
	<path d="M 24,96 L 80,96" fill="none" stroke="black"/>		<path d="M 24,96 L 80,96" fill="none" stroke="black"></path>
	<path d="M 200,96 L 240,96" fill="none" stroke="black"/>		<path d="M 200,96 L 248,96" fill="none" stroke="black"></path>
	<path d="M 320,96 L 360,96" fill="none" stroke="black"/>		<path d="M 312,96 L 360,96" fill="none" stroke="black"></path>
	<path d="M 416,96 L 472,96" fill="none" stroke="black"/>		<path d="M 416,96 L 472,96" fill="none" stroke="black"></path>
	<path d="M 48,112 L 104,112" fill="none" stroke="black"/>		<path d="M 48,112 L 104,112" fill="none" stroke="black"></path>
	<path d="M 440,112 L 496,112" fill="none" stroke="black"/>		<path d="M 440,112 L 496,112" fill="none" stroke="black"></path>
	<path d="M 48,144 L 104,144" fill="none" stroke="black"/>		<path d="M 48,144 L 104,144" fill="none" stroke="black"></path>
	<path d="M 440,144 L 496,144" fill="none" stroke="black"/>		<path d="M 440,144 L 496,144" fill="none" stroke="black"></path>
	<path d="M 64,160 L 120,160" fill="none" stroke="black"/>		<path d="M 64,160 L 120,160" fill="none" stroke="black"></path>
	<path d="M 200,160 L 240,160" fill="none" stroke="black"/>		<path d="M 200,160 L 248,160" fill="none" stroke="black"></path>
	<path d="M 320,160 L 360,160" fill="none" stroke="black"/>		<path d="M 312,160 L 360,160" fill="none" stroke="black"></path>
	<path d="M 480,160 L 536,160" fill="none" stroke="black"/>		<path d="M 480,160 L 536,160" fill="none" stroke="black"></path>
	<path d="M 176,176 L 192,176" fill="none" stroke="black"/>		<path d="M 176,176 L 192,176" fill="none" stroke="black"></path>
	<path d="M 368,176 L 384,176" fill="none" stroke="black"/>		<path d="M 368,176 L 384,176" fill="none" stroke="black"></path>
	<path d="M 64,192 L 120,192" fill="none" stroke="black"/>		<path d="M 64,192 L 120,192" fill="none" stroke="black"></path>
	<path d="M 200,192 L 240,192" fill="none" stroke="black"/>		<path d="M 200,192 L 248,192" fill="none" stroke="black"></path>
	<path d="M 320,192 L 360,192" fill="none" stroke="black"/>		<path d="M 312,192 L 360,192" fill="none" stroke="black"></path>
	<path d="M 480,192 L 536,192" fill="none" stroke="black"/>		<path d="M 480,192 L 536,192" fill="none" stroke="black"></path>
	<path d="M 8,208 L 176,208" fill="none" stroke="black"/>		<path d="M 8,208 L 176,208" fill="none" stroke="black"></path>
	<path d="M 384,208 L 552,208" fill="none" stroke="black"/>		<path d="M 384,208 L 552,208" fill="none" stroke="black"></path>
	<path d="M 384,240 L 448,240" fill="none" stroke="black"/>		<path d="M 384,240 L 448,240" fill="none" stroke="black"></path>
	<path d="M 488,240 L 552,240" fill="none" stroke="black"/>		<path d="M 488,240 L 552,240" fill="none" stroke="black"></path>
	<path d="M 320,256 L 360,256" fill="none" stroke="black"/>		<path d="M 312,256 L 360,256" fill="none" stroke="black"></path>
	<path d="M 416,256 L 472,256" fill="none" stroke="black"/>		<path d="M 416,256 L 472,256" fill="none" stroke="black"></path>
	<path d="M 368,272 L 384,272" fill="none" stroke="black"/>		<path d="M 368,272 L 384,272" fill="none" stroke="black"></path>
	<path d="M 320,288 L 360,288" fill="none" stroke="black"/>		<path d="M 312,288 L 360,288" fill="none" stroke="black"></path>
	<path d="M 416,288 L 472,288" fill="none" stroke="black"/>		<path d="M 416,288 L 472,288" fill="none" stroke="black"></path>
	<path d="M 448,304 L 504,304" fill="none" stroke="black"/>		<path d="M 448,304 L 504,304" fill="none" stroke="black"></path>
	<path d="M 448,336 L 504,336" fill="none" stroke="black"/>		<path d="M 448,336 L 504,336" fill="none" stroke="black"></path>
	<path d="M 320,352 L 360,352" fill="none" stroke="black"/>		<path d="M 312,352 L 360,352" fill="none" stroke="black"></path>
	<path d="M 480,352 L 536,352" fill="none" stroke="black"/>		<path d="M 480,352 L 536,352" fill="none" stroke="black"></path>
	<path d="M 368,368 L 384,368" fill="none" stroke="black"/>		<path d="M 368,368 L 384,368" fill="none" stroke="black"></path>
	<path d="M 320,384 L 360,384" fill="none" stroke="black"/>		<path d="M 312,384 L 360,384" fill="none" stroke="black"></path>
	<path d="M 480,384 L 536,384" fill="none" stroke="black"/>		<path d="M 480,384 L 536,384" fill="none" stroke="black"></path>
	<path d="M 208,416 L 352,416" fill="none" stroke="black"/>		<path d="M 208,416 L 352,416" fill="none" stroke="black"></path>
	<path d="M 384,416 L 552,416" fill="none" stroke="black"/>		<path d="M 384,416 L 552,416" fill="none" stroke="black"></path>
	<circle cx="24" cy="448" r="6" class="closeddot" fill="black"/>		<circle cx="8" cy="448" r="6" class="closeddot" fill="black"></c
	<circle cx="200" cy="80" r="6" class="closeddot" fill="black"/>		ircle>
	<circle cx="200" cy="176" r="6" class="closeddot" fill="black"/>		<circle cx="200" cy="80" r="6" class="closeddot" fill="black"></
	<circle cx="360" cy="80" r="6" class="closeddot" fill="black"/>		circle>
	<circle cx="360" cy="176" r="6" class="closeddot" fill="black"/>		<circle cx="200" cy="176" r="6" class="closeddot" fill="black"><
	<circle cx="360" cy="272" r="6" class="closeddot" fill="black"/>		/circle>
	<circle cx="360" cy="368" r="6" class="closeddot" fill="black"/>		<circle cx="360" cy="80" r="6" class="closeddot" fill="black"></
			circle>
			<circle cx="360" cy="176" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="360" cy="272" r="6" class="closeddot" fill="black"><
			/circle>
			<circle cx="360" cy="368" r="6" class="closeddot" fill="black"><
			/circle>
	<g class="text">		<g class="text">
	<text x="92" y="36">DC</text>		<text x="92" y="36">DC</text>
	<text x="112" y="36">1</text>		<text x="112" y="36">1</text>
	<text x="468" y="36">DC</text>		<text x="468" y="36">DC</text>
	<text x="488" y="36">2</text>		<text x="488" y="36">2</text>
	<text x="52" y="84">NF1A</text>		<text x="52" y="84">NF1A</text>
	<text x="220" y="84">PE1A</text>		<text x="228" y="84">PE1A</text>
	<text x="340" y="84">PE2A</text>		<text x="332" y="84">PE2A</text>
	<text x="444" y="84">NF2A</text>		<text x="444" y="84">NF2A</text>
	<text x="76" y="132">NF1B</text>		<text x="76" y="132">NF1B</text>
	<text x="468" y="132">NF2B</text>		<text x="468" y="132">NF2B</text>
	<text x="92" y="180">NF1C</text>		<text x="92" y="180">NF1C</text>
	<text x="220" y="180">PE1B</text>		<text x="228" y="180">PE1B</text>
	<text x="340" y="180">PE2B</text>		<text x="332" y="180">PE2B</text>
	<text x="508" y="180">NF2C</text>		<text x="508" y="180">NF2C</text>
	<text x="276" y="212">Provider</text>		<text x="276" y="228">Provider</text>
	<text x="280" y="244">Network</text>		<text x="280" y="244">Network</text>
	<text x="460" y="244">DC</text>		<text x="460" y="244">DC</text>
	<text x="480" y="244">3</text>		<text x="480" y="244">3</text>
	<text x="340" y="276">PE3A</text>		<text x="332" y="276">PE3A</text>
	<text x="444" y="276">NF3A</text>		<text x="444" y="276">NF3A</text>
	<text x="476" y="324">NF3B</text>		<text x="476" y="324">NF3B</text>
	<text x="340" y="372">PE3B</text>		<text x="332" y="372">PE3B</text>
	<text x="508" y="372">NF3C</text>		<text x="508" y="372">NF3C</text>
	<text x="52" y="452">SDP,</text>		<text x="36" y="452">SDP,</text>
	<text x="92" y="452">with</text>		<text x="76" y="452">with</text>
	<text x="164" y="452">fine-grained</text>		<text x="148" y="452">fine-grained</text>
	<text x="232" y="452">QoS</text>		<text x="216" y="452">QoS</text>
	<text x="292" y="452">(dedicated</text>		<text x="276" y="452">(dedicated</text>
	<text x="376" y="452">resources</text>		<text x="360" y="452">resources</text>
	<text x="432" y="452">per</text>		<text x="416" y="452">per</text>
	<text x="464" y="452">RFC</text>		<text x="448" y="452">RFC</text>
	<text x="500" y="452">9543</text>		<text x="484" y="452">9543</text>
	<text x="536" y="452">NS)</text>		<text x="536" y="452">Network</text>
			<text x="48" y="468">Slices)</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+-------- DC 1-------+ +-----------------+ +-------- DC 2-------+		+-------- DC 1-------+ +-----------------+ +-------- DC 2-------+
	| | | | | |		| | | | | |
	| +------+ | +----+ +----+ | +------+ |		| +------+ | +-----+ +-----+ | +------+ |
	| | NF1A | +--*PE1A| |PE2A*--+ | NF2A | |		| | NF1A | +--* PE1A| |PE2A *--+ | NF2A | |
	| +------+ | +----+ +----+ | +------+ |		| +------+ | +-----+ +-----+ | +------+ |
	| +------+ | | | | +------+ |		| +------+ | | | | +------+ |
	| | NF1B | | | | | | NF2B | |		| | NF1B | | | | | | NF2B | |
	| +------+ | | | | +------+ |		| +------+ | | | | +------+ |
	| +------+ | +----+ +----+ | +------+ |		| +------+ | +-----+ +-----+ | +------+ |
	| | NF1C | +--*PE1B| |PE2B*--+ | NF2C | |		| | NF1C | +--* PE1B| |PE2B *--+ | NF2C | |
	| +------+ | +----+ +----+ | +------+ |		| +------+ | +-----+ +-----+ | +------+ |
	+--------------------+ | Provider | +--------------------+		+--------------------+ | | +--------------------+
	| |		| Provider |
	| Network | +--------DC 3--------+		| Network | +--------DC 3--------+
	| +----+ | +------+ |		| +-----+ | +------+ |
	| |PE3A*--+ | NF3A | |		| |PE3A *--+ | NF3A | |
	| +----+ | +------+ |		| +-----+ | +------+ |
	| | | +------+ |		| | | +------+ |
	| | | | NF3B | |		| | | | NF3B | |
	| | | +------+ |		| | | +------+ |
	| +----+ | +------+ |		| +-----+ | +------+ |
	| |PE3B*--+ | NF3C | |		| |PE3B *--+ | NF3C | |
	| +----+ | +------+ |		| +-----+ | +------+ |
	| | | |		| | | |
	+-----------------+ +--------------------+		+-----------------+ +--------------------+
	* SDP, with fine-grained QoS (dedicated resources per RFC 9543 NS)		* SDP, with fine-grained QoS (dedicated resources per RFC 9543 Network
			Slices)
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>Let us consider 5G slice "X" that uses some of the network functions in		<t>Let us consider 5G Network Slice "X" that uses some of the network fu nctions 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 Network 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 Network 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 "DC 1"
	might be sending traffic to multiple NFs in "DC2", but this is		might be sending traffic to multiple NFs in "DC 2", 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 Network Slice "X" from "DC 1" to "DC 2" (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 "DC 1" 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 6492 ¶
	</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		<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 DC 1, as this is the total bandwidth that DC 1
	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		metric. There would be a many-to-one mapping of network slices to Flex-Algori
	thms.</t>		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 at the time of writing this document) 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 "DC 1" to "DC 2"
	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
	instantiated that needs 0.8 Gbps from "DC1" to "DC2". The transport		instantiated that needs 0.8 Gbps from "DC 1" to "DC 2". The transport
	controller would increase its notion of the bandwidth requirement		controller would increase its notion of the bandwidth requirement
	from "DC1" to "DC2" from 12 Gbps to 12.8 Gbps to accommodate the		from "DC 1" to "DC 2" from 12 Gbps to 12.8 Gbps to accommodate the
	additional expected traffic.</t>		additional expected traffic.</t>
	<table anchor="_table-y">		<table anchor="_table-y">
	<name>Inter-DC Traffic Demand Matrix (Slice Y)</name>		<name>Inter-DC Traffic Demand Matrix (Slice Y)</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>
	skipping to change at line 6297 ¶		skipping to change at line 6621 ¶
	<td align="left">DC 3</td>		<td align="left">DC 3</td>
	<td align="left">2.6</td>		<td align="left">2.6</td>
	<td align="left">3</td>		<td align="left">3</td>
	<td align="left">n/a</td>		<td align="left">n/a</td>
	<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 "DC 1" to "DC 2" bandwidth requirement to bandwidth reservations of TE
	LSPs from "DC1" to "DC2". For example, if the routing configuration is		LSPs from "DC 1" to "DC 2". 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 "DC 1" to "DC 2" 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 "DC 1" to "DC 2" 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 "DC 1" that
	causes traffic from "DC1" to land on "PE1B", rather than "PE1A". The		causes traffic from "DC 1" 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
			<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 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 L2VPN/L3VPNs that are used to deliver Network Slice Services.
	The correlation between an LxVPN instance and a Network Slice Service		The correlation between an L2VPN/L3VPN instance and a Network Slice Service
	is maintained using "parent-service-id" attribute (<xref section="7.3" sectionFo		is maintained using the "parent-service-id" attribute (<xref section="7.3" secti
	rmat="of" target="RFC9182"/>).</t>		onFormat="of" target="RFC9182"/>).</t>
	</li>		</li>
	<li>		<li>
	<t>Means to report a set of network performance metrics to assess
	whether the agreed slice service objectives are honored. These means are used fo		<t>Providers should provide the means to report a set of network perfo
	r SLO monitoring and violation detect purposes. For example,		rmance metrics to assess
	<xref target="RFC9375"/> can be used to report links' one-way delay,		whether the agreed Slice Service objectives are honored. These means are used fo
	one-way delay variation, etc. Both conventional active/passive		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.		<t>Providers should have the means to report and expose observed perfo
	For example, <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/> exposes		rmance metrics and other OAM state to customer.
	a set of statistics per SDP, connectivity construct, and connection group.</t>		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
	g"/>) is a design choice of service operators that may be a function of, e.g., t		<t>The mapping of 5G Network Slices to Transport Network Slices (see <xref
	he number of instantiated slices, requested services, or local engineering capab		target="sec-mapping"/>) is a design choice of service operators that may be a f
	ilities and guidelines. However, operators should carefully consider means to ea		unction of, e.g., the number of instantiated slices, requested services, or loca
	se slice migration strategies. For example, a provider may initially adopt a 1-t		l engineering capabilities and guidelines. However, operators should carefully c
	o-1 mapping if it has to instantiate just a few Network Slices and accommodate t		onsider means to ease slice migration strategies. For example, a provider may in
	he need of only a few customers. That provider may decide to move to an N-to-1 m		itially adopt a 1-to-1 mapping if it has to instantiate just a few network slice
	apping for aggregation/scalability purposes if sustained increased slice demand		s and accommodate the need of only a few customers. That provider may decide to
	is observed.</t>		move to an M-to-1 mapping for aggregation/scalability purposes if sustained incr
	<t>Putting in place adequate automation means to realize Network Slices (i		eased slice demand is observed.</t>
	ncluding the adjustment of Slice Services to Network Slices mapping) would ease		<t>Putting in place adequate automation means to realize network slices (i
	slice migration operations.</t>		ncluding the adjustment of the mapping of Slice Services to network slices) woul
	<t>The realization model described in the document inherits the scalabilit		d ease slice migration operations.</t>
	y properties of the underlying L2VPN and L3VPN technologies (<xref target="sec-o		<t>The realization model described in this document inherits the scalabili
	ver-rea-model"/>). Readers may refer, for example, to <xref section="13" section		ty properties of the underlying L2VPN and L3VPN technologies (<xref target="sec-
	Format="of" target="RFC4365"/> or <xref section="1.2.5" sectionFormat="of" targe		over-rea-model"/>). Readers may refer, for example, to <xref section="13" sectio
	t="RFC6624"/> for a scalability assessment of some of these technologies. Provid		nFormat="of" target="RFC4365"/> or <xref section="1.2.5" sectionFormat="of" targ
	ers may adjust the mapping model to better handle local scalability constraints.		et="RFC6624"/> for a scalability assessment of some of these technologies. Provi
	</t>		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
	</dd>		privilege is provided before granting access to specific data or
	<dt>Data Confidentiality and Integrity of an IETF Network Slice:</dt>		performing specific actions.</t>
	<dd>
	<t>As described in <xref section="5.1.2.1" sectionFormat="of" target="
	RFC9543"/>, the customer might request a Service Level Expectation (SLE) that ma
	ndates encryption.</t>
	</dd>		</dd>
	<dt/>
			<dt>Data Confidentiality and Integrity of an RFC 9543 Network Slice:</dt
			>
	<dd>		<dd>
	<t>This can be achieved, e.g., by mapping the traffic to an underlay t		<t>As described in <xref section="5.1.2.1" sectionFormat="of"
	ransport (<xref target="transport-plane-mapping-models"/>) that uses only MACsec		target="RFC9543"/>, the customer might request a Service Level
	-encrypted links.</t>		Expectation (SLE) that mandates encryption.</t>
			<t>This can be achieved, e.g., by mapping the traffic to an underlay
			transport (<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		addresses and the specific S-NSSAIs of slices, <xref target="sec-ip-hof"/> descr
	n approach where some or all S-NSSAI bits		ibes an approach where some or all S-NSSAI bits
	are embedded in an IPv6 address using an algorithm approach. An attacker from wi		are embedded in an IPv6 address using an algorithm approach. An attacker from wi
	thin the transport network		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		service disruption. Note that such an attacker from within the Transport Network
	may inflict more damage (e.g., randomly drop packets).</t>		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>
	<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>
	<reference anchor="TS-23.501" target="https://portal.3gpp.org/desktopmod
	ules/Specifications/SpecificationDetails.aspx?specificationId=3144">		<reference anchor="TS-23.501" target="https://www.3gpp.org/ftp/Specs/arc
			hive/23_series/23.501/23501-j50.zip">
	<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"/>		<date month="September" year="2025"/>
	</front>		</front>
			<seriesInfo name="3GPP TS" value="23.501"/>
			<refcontent>Version 19.5.0, Release 19</refcontent>
	</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://www.3gpp.org/ftp/Specs/arc
			hive/28_series/28.530/28530-j00.zip">
	<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 abbrev="3GPP">3rd Generation Partnership Project</or ganization>
	</author>		</author>
	<date year="2024"/>		<date month="March" year="2025"/>
	</front>		</front>
			<seriesInfo name="3GPP TS" value="28.530"/>
			<refcontent>Version 19.0.0, Release 19</refcontent>
	</reference>		</reference>
	<reference anchor="O-RAN.WG9.XPSAAS" target="https://www.o-ran.org/speci
	fications">		<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="2025" month="October"/>
	</front>		</front>
			<refcontent>O-RAN.WG9.XPSAAS, Version 09.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?>
	<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>
	>
	<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 approach in <xref target="sec-ip-hof"/> may be used, wi th 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 7135 ¶
	|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		<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		allocated from 2001:db8:a::/96, while "NF-B" uses a set of tunnel termination
	on		points with per-slice IP addresses allocated from 2001:db8:b::/96. This examp
	points with per-slice IP addresses allocated from 2001:db8:b:0::/96. This exa		le shows
	mple shows		two slices: "customer A eMBB" (SST=1, SD-00001) and "customer B MIoT" (SST=3,
	two slices: "customer A eMBB" (SST-01, SD-00001) and "customer B Massive Inte		SD-00003).
	rnet of Things (MIoT)" (SST-03, 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/		<artwork type="svg" align="center">
	svg" version="1.1" height="352" width="552" viewBox="0 0 552 352" class="diagram		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="352" width="552" v
	" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="		iewBox="0 0 552 352" class="diagram" text-anchor="middle" font-family="monospace
	round">		" 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>
	<path d="M 48,80 L 48,128" fill="none" stroke="black"/>		<path d="M 48,80 L 48,128" fill="none" stroke="black"></path>
	<path d="M 48,224 L 48,272" fill="none" stroke="black"/>		<path d="M 48,224 L 48,272" fill="none" stroke="black"></path>
	<path d="M 64,128 L 64,144" fill="none" stroke="black"/>		<path d="M 64,128 L 64,144" fill="none" stroke="black"></path>
	<path d="M 64,208 L 64,224" fill="none" stroke="black"/>		<path d="M 64,208 L 64,224" fill="none" stroke="black"></path>
	<path d="M 128,128 L 128,144" fill="none" stroke="black"/>		<path d="M 128,128 L 128,144" fill="none" stroke="black"></path>
	<path d="M 128,208 L 128,224" fill="none" stroke="black"/>		<path d="M 128,208 L 128,224" fill="none" stroke="black"></path>
	<path d="M 152,96 L 152,128" fill="none" stroke="black"/>		<path d="M 152,96 L 152,128" fill="none" stroke="black"></path>
	<path d="M 152,224 L 152,256" fill="none" stroke="black"/>		<path d="M 152,224 L 152,256" fill="none" stroke="black"></path>
	<path d="M 176,128 L 176,144" fill="none" stroke="black"/>		<path d="M 176,128 L 176,144" fill="none" stroke="black"></path>
	<path d="M 176,208 L 176,224" fill="none" stroke="black"/>		<path d="M 176,208 L 176,224" fill="none" stroke="black"></path>
	<path d="M 264,128 L 264,144" fill="none" stroke="black"/>		<path d="M 264,128 L 264,144" fill="none" stroke="black"></path>
	<path d="M 264,208 L 264,224" fill="none" stroke="black"/>		<path d="M 264,208 L 264,224" fill="none" stroke="black"></path>
	<path d="M 296,96 L 296,128" fill="none" stroke="black"/>		<path d="M 296,96 L 296,128" fill="none" stroke="black"></path>
	<path d="M 296,224 L 296,256" fill="none" stroke="black"/>		<path d="M 296,224 L 296,256" fill="none" stroke="black"></path>
	<path d="M 312,128 L 312,144" fill="none" stroke="black"/>		<path d="M 312,128 L 312,144" fill="none" stroke="black"></path>
	<path d="M 312,208 L 312,224" fill="none" stroke="black"/>		<path d="M 312,208 L 312,224" fill="none" stroke="black"></path>
	<path d="M 352,112 L 352,144" fill="none" stroke="black"/>		<path d="M 352,112 L 352,144" fill="none" stroke="black"></path>
	<path d="M 352,224 L 352,248" fill="none" stroke="black"/>		<path d="M 352,208 L 352,248" fill="none" stroke="black"></path>
	<path d="M 376,128 L 376,144" fill="none" stroke="black"/>		<path d="M 376,128 L 376,144" fill="none" stroke="black"></path>
	<path d="M 376,208 L 376,224" fill="none" stroke="black"/>		<path d="M 376,208 L 376,224" fill="none" stroke="black"></path>
	<path d="M 424,128 L 424,144" fill="none" stroke="black"/>		<path d="M 424,128 L 424,144" fill="none" stroke="black"></path>
	<path d="M 424,208 L 424,224" fill="none" stroke="black"/>		<path d="M 424,208 L 424,224" fill="none" stroke="black"></path>
	<path d="M 488,128 L 488,144" fill="none" stroke="black"/>		<path d="M 488,128 L 488,144" fill="none" stroke="black"></path>
	<path d="M 488,208 L 488,224" fill="none" stroke="black"/>		<path d="M 488,208 L 488,224" fill="none" stroke="black"></path>
	<path d="M 504,80 L 504,128" fill="none" stroke="black"/>		<path d="M 504,80 L 504,128" fill="none" stroke="black"></path>
	<path d="M 504,224 L 504,272" fill="none" stroke="black"/>		<path d="M 504,224 L 504,272" fill="none" stroke="black"></path>
	<path d="M 544,128 L 544,224" fill="none" stroke="black"/>		<path d="M 544,128 L 544,224" fill="none" stroke="black"></path>
	<path d="M 8,128 L 40,128" fill="none" stroke="black"/>		<path d="M 8,128 L 40,128" fill="none" stroke="black"></path>
	<path d="M 128,128 L 176,128" fill="none" stroke="black"/>		<path d="M 128,128 L 176,128" fill="none" stroke="black"></path>
	<path d="M 264,128 L 312,128" fill="none" stroke="black"/>		<path d="M 264,128 L 312,128" fill="none" stroke="black"></path>
	<path d="M 376,128 L 424,128" fill="none" stroke="black"/>		<path d="M 376,128 L 424,128" fill="none" stroke="black"></path>
	<path d="M 512,128 L 544,128" fill="none" stroke="black"/>		<path d="M 512,128 L 544,128" fill="none" stroke="black"></path>
	<path d="M 56,158 L 144,158" fill="none" stroke="black"/>		<path d="M 56,158 L 144,158" fill="none" stroke="black"></path>
	<path d="M 56,162 L 144,162" fill="none" stroke="black"/>		<path d="M 56,162 L 144,162" fill="none" stroke="black"></path>
	<path d="M 160,158 L 280,158" fill="none" stroke="black"/>		<path d="M 160,158 L 280,158" fill="none" stroke="black"></path>
	<path d="M 160,162 L 280,162" fill="none" stroke="black"/>		<path d="M 160,162 L 280,162" fill="none" stroke="black"></path>
	<path d="M 296,158 L 496,158" fill="none" stroke="black"/>		<path d="M 296,158 L 496,158" fill="none" stroke="black"></path>
	<path d="M 296,162 L 496,162" fill="none" stroke="black"/>		<path d="M 296,162 L 496,162" fill="none" stroke="black"></path>
	<path d="M 64,176 L 128,176" fill="none" stroke="black"/>		<path d="M 64,176 L 128,176" fill="none" stroke="black"></path>
	<path d="M 312,176 L 376,176" fill="none" stroke="black"/>		<path d="M 312,176 L 376,176" fill="none" stroke="black"></path>
	<path d="M 56,190 L 144,190" fill="none" stroke="black"/>		<path d="M 56,190 L 144,190" fill="none" stroke="black"></path>
	<path d="M 56,194 L 144,194" fill="none" stroke="black"/>		<path d="M 56,194 L 144,194" fill="none" stroke="black"></path>
	<path d="M 160,190 L 280,190" fill="none" stroke="black"/>		<path d="M 160,190 L 280,190" fill="none" stroke="black"></path>
	<path d="M 160,194 L 280,194" fill="none" stroke="black"/>		<path d="M 160,194 L 280,194" fill="none" stroke="black"></path>
	<path d="M 296,190 L 496,190" fill="none" stroke="black"/>		<path d="M 296,190 L 496,190" fill="none" stroke="black"></path>
	<path d="M 296,194 L 496,194" fill="none" stroke="black"/>		<path d="M 296,194 L 496,194" fill="none" stroke="black"></path>
	<path d="M 8,224 L 40,224" fill="none" stroke="black"/>		<path d="M 8,224 L 40,224" fill="none" stroke="black"></path>
	<path d="M 128,224 L 176,224" fill="none" stroke="black"/>		<path d="M 128,224 L 176,224" fill="none" stroke="black"></path>
	<path d="M 264,224 L 312,224" fill="none" stroke="black"/>		<path d="M 264,224 L 312,224" fill="none" stroke="black"></path>
	<path d="M 376,224 L 424,224" fill="none" stroke="black"/>		<path d="M 376,224 L 424,224" fill="none" stroke="black"></path>
	<path d="M 512,224 L 544,224" fill="none" stroke="black"/>		<path d="M 512,224 L 544,224" fill="none" stroke="black"></path>
	<polygon class="arrowhead" points="512,224 500,218.4 500,229.6" fi		<polygon class="arrowhead" points="512,224 500,218.4 500,229.6" fi
	ll="black" transform="rotate(270,504,224)"/>		ll="black" transform="rotate(270,504,224)"></polygon>
	<polygon class="arrowhead" points="512,128 500,122.4 500,133.6" fi		<polygon class="arrowhead" points="512,128 500,122.4 500,133.6" fi
	ll="black" transform="rotate(90,504,128)"/>		ll="black" transform="rotate(90,504,128)"></polygon>
	<polygon class="arrowhead" points="360,224 348,218.4 348,229.6" fi		<polygon class="arrowhead" points="360,208 348,202.4 348,213.6" fi
	ll="black" transform="rotate(270,352,224)"/>		ll="black" transform="rotate(270,352,208)"></polygon>
	<polygon class="arrowhead" points="360,144 348,138.4 348,149.6" fi		<polygon class="arrowhead" points="360,144 348,138.4 348,149.6" fi
	ll="black" transform="rotate(90,352,144)"/>		ll="black" transform="rotate(90,352,144)"></polygon>
	<polygon class="arrowhead" points="56,224 44,218.4 44,229.6" fill=		<polygon class="arrowhead" points="56,224 44,218.4 44,229.6" fill=
	"black" transform="rotate(270,48,224)"/>		"black" transform="rotate(270,48,224)"></polygon>
	<polygon class="arrowhead" points="56,128 44,122.4 44,133.6" fill=		<polygon class="arrowhead" points="56,128 44,122.4 44,133.6" fill=
	"black" transform="rotate(90,48,128)"/>		"black" transform="rotate(90,48,128)"></polygon>
	<circle cx="16" cy="320" r="6" class="opendot" fill="white" stroke		<circle cx="16" cy="320" r="6" class="opendot" fill="white" stroke
	="black"/>		="black"></circle>
	<circle cx="16" cy="336" r="6" class="closeddot" fill="black"/>		<circle cx="16" cy="336" r="6" class="closeddot" fill="black"></ci
	<circle cx="48" cy="160" r="6" class="opendot" fill="white" stroke		rcle>
	="black"/>		<circle cx="48" cy="160" r="6" class="opendot" fill="white" stroke
	<circle cx="48" cy="192" r="6" class="opendot" fill="white" stroke		="black"></circle>
	="black"/>		<circle cx="48" cy="192" r="6" class="opendot" fill="white" stroke
	<circle cx="152" cy="160" r="6" class="closeddot" fill="black"/>		="black"></circle>
	<circle cx="152" cy="192" r="6" class="closeddot" fill="black"/>		<circle cx="152" cy="160" r="6" class="closeddot" fill="black"></c
	<circle cx="288" cy="160" r="6" class="closeddot" fill="black"/>		ircle>
	<circle cx="288" cy="192" r="6" class="closeddot" fill="black"/>		<circle cx="152" cy="192" r="6" class="closeddot" fill="black"></c
	<circle cx="504" cy="160" r="6" class="opendot" fill="white" strok		ircle>
	e="black"/>		<circle cx="288" cy="160" r="6" class="closeddot" fill="black"></c
	<circle cx="504" cy="192" r="6" class="opendot" fill="white" strok		ircle>
	e="black"/>		<circle cx="288" cy="192" r="6" class="closeddot" fill="black"></c
			ircle>
			<circle cx="504" cy="160" r="6" class="opendot" fill="white" strok
			e="black"></circle>
			<circle cx="504" cy="192" r="6" class="opendot" fill="white" strok
			e="black"></circle>
	<g class="text">		<g class="text">
	<text x="72" y="36">2001:db8:a::/96</text>		<text x="72" y="36">2001:db8:a::/96</text>
	<text x="164" y="36">(NF-A)</text>		<text x="164" y="36">(NF-A)</text>
	<text x="424" y="36">2001:db8:b::/96</text>		<text x="424" y="36">2001:db8:b::/96</text>
	<text x="516" y="36">(NF-B)</text>		<text x="516" y="36">(NF-B)</text>
	<text x="96" y="68">2001:db8:a::100:1/128</text>		<text x="96" y="68">2001:db8:a::100:1/128</text>
	<text x="392" y="68">2001:db8:b::100:1/128</text>		<text x="392" y="68">2001:db8:b::100:1/128</text>
	<text x="168" y="100">-</text>		<text x="168" y="100">-</text>
	<text x="184" y="100">-</text>		<text x="184" y="100">-</text>
	<text x="200" y="100">-</text>		<text x="200" y="100">-</text>
	skipping to change at line 7790 ¶		skipping to change at line 7249 ¶
	<text x="56" y="132">-</text>		<text x="56" y="132">-</text>
	<text x="220" y="132">Provider</text>		<text x="220" y="132">Provider</text>
	<text x="496" y="132">-</text>		<text x="496" y="132">-</text>
	<text x="28" y="180">NF</text>		<text x="28" y="180">NF</text>
	<text x="148" y="180">PE</text>		<text x="148" y="180">PE</text>
	<text x="176" y="180">|</text>		<text x="176" y="180">|</text>
	<text x="264" y="180">|</text>		<text x="264" y="180">|</text>
	<text x="284" y="180">PE</text>		<text x="284" y="180">PE</text>
	<text x="436" y="180">L2/L3+.......+</text>		<text x="436" y="180">L2/L3+.......+</text>
	<text x="524" y="180">NF</text>		<text x="524" y="180">NF</text>
	<text x="352" y="212">v</text>
	<text x="56" y="228">-</text>		<text x="56" y="228">-</text>
	<text x="224" y="228">Network</text>		<text x="224" y="228">Network</text>
	<text x="496" y="228">-</text>		<text x="496" y="228">-</text>
	<text x="168" y="260">-</text>		<text x="168" y="260">-</text>
	<text x="184" y="260">-</text>		<text x="184" y="260">-</text>
	<text x="200" y="260">-</text>		<text x="200" y="260">-</text>
	<text x="216" y="260">-</text>		<text x="216" y="260">-</text>
	<text x="232" y="260">-</text>		<text x="232" y="260">-</text>
	<text x="248" y="260">-</text>		<text x="248" y="260">-</text>
	<text x="264" y="260">-</text>		<text x="264" y="260">-</text>
	skipping to change at line 7815 ¶		skipping to change at line 7273 ¶
	<text x="384" y="292">2001:db8:b::300:3/128</text>		<text x="384" y="292">2001:db8:b::300:3/128</text>
	<text x="52" y="324">Tunnel</text>		<text x="52" y="324">Tunnel</text>
	<text x="112" y="324">(IPsec,</text>		<text x="112" y="324">(IPsec,</text>
	<text x="172" y="324">GTP-U,</text>		<text x="172" y="324">GTP-U,</text>
	<text x="224" y="324">etc.)</text>		<text x="224" y="324">etc.)</text>
	<text x="296" y="324">termination</text>		<text x="296" y="324">termination</text>
	<text x="368" y="324">point</text>		<text x="368" y="324">point</text>
	<text x="40" y="340">SDP</text>		<text x="40" y="340">SDP</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B)		2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B)
	2001:db8:a::100:1/128 2001:db8:b::100:1/128		2001:db8:a::100:1/128 2001:db8:b::100:1/128
	| |		| |
	| + - - - - - - - - + eMBB (SST=1) |		| + - - - - - - - - + eMBB (SST=1) |
	| | | | |		| | | | |
	+----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+		+----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+
	| | | | | | v | | | |		| | | | | | v | | | |
	| o============*================*==========================o |		| o============*================*==========================o |
	| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |		| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |
	| o============*================*==========================o |		| o============*================*==========================o |
	| | | | | | v | | | |		| | | | | | ^ | | | |
	+----^-+ +--+--+ Network +---+-+ ^ +-----+ +-^----+		+----^-+ +--+--+ Network +---+-+ | +-----+ +-^----+
	| | | | |		| | | | |
			----^-+ +--+--+ Network +---+-+ <span class="insert">|</span> +-----+ +-^----+
	| + - - - - - - - - + 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 7357 ¶
	<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 7401 ¶
	<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=
	</rfc>		</rfc>
End of changes. 399 change blocks.
	4505 lines changed or deleted		2665 lines changed or added
This html diff was produced by rfcdiff 1.48.