rfc9433.original.xml | rfc9433.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" consensus="true" | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" | |||
docName="draft-ietf-dmm-srv6-mobile-uplane-24" ipr="trust200902" obsoletes="" u | info" consensus="true" docName="draft-ietf-dmm-srv6-mobile-uplane-24" number="94 | |||
pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" s | 33" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" sy | |||
ortRefs="true" version="3"> | mRefs="true" sortRefs="true" version="3"> | |||
<!-- xml2rfc v2v3 conversion 3.9.0 --> | ||||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<front> | <front> | |||
<title abbrev="SRv6 Mobile User-Plane"> | ||||
Segment Routing IPv6 for Mobile User Plane</title> | <title abbrev="SRv6 Mobile User Plane">Segment Routing over IPv6 for the Mob | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-dmm-srv6-mobile-uplane-2 | ile | |||
4"/> | User Plane</title> | |||
<seriesInfo name="RFC" value="9433"/> | ||||
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima" role ="editor"> | <author fullname="Satoru Matsushima" initials="S." surname="Matsushima" role ="editor"> | |||
<organization abbrev="SoftBank">SoftBank</organization> | <organization abbrev="SoftBank">SoftBank</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street/> | <street/> | |||
<city/> | <city/> | |||
<region/> | <region/> | |||
<code/> | <code/> | |||
<country>Japan</country> | <country>Japan</country> | |||
</postal> | </postal> | |||
skipping to change at line 84 ¶ | skipping to change at line 85 ¶ | |||
<postal> | <postal> | |||
<street/> | <street/> | |||
<city/> | <city/> | |||
<region/> | <region/> | |||
<code/> | <code/> | |||
<country>Canada</country> | <country>Canada</country> | |||
</postal> | </postal> | |||
<email>daniel.voyer@bell.ca</email> | <email>daniel.voyer@bell.ca</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2023"/> | <date year="2023" month="July" /> | |||
<workgroup>DMM Working Group</workgroup> | <area>int</area> | |||
<workgroup>dmm</workgroup> | ||||
<abstract> | <abstract> | |||
<t> | <t> | |||
This document discusses the applicability of SRv6 (Segment Routing IPv6) | This document discusses the applicability of Segment Routing over IPv6 | |||
to the user-plane of mobile networks. The network programming nature | (SRv6) to the user plane of mobile networks. The network programming | |||
of SRv6 accomplishes mobile user-plane functions in a simple manner. | nature of SRv6 accomplishes mobile user-plane functions in a simple | |||
The statelessness of SRv6 and its ability to control both service | manner. The statelessness of SRv6 and its ability to control both | |||
layer path and underlying transport can be beneficial to the mobile | service layer path and underlying transport can be beneficial to the | |||
user-plane, providing flexibility, end-to-end network slicing, and | mobile user plane, providing flexibility, end-to-end network slicing, | |||
SLA control for various applications. </t> | and Service Level Agreement (SLA) control for various | |||
applications. </t> | ||||
<t> | <t> | |||
This document discusses how SRv6 (Segment Routing over IPv6) could be us | This document discusses how SRv6 could be used as the user plane of | |||
ed as user-plane of mobile networks. This document also specifies the SRv6 Segme | mobile networks. This document also specifies the SRv6 | |||
nt Endpoint behaviors required for mobility use-cases. | Endpoint Behaviors required for mobility use cases. | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t> In mobile networks, mobility systems provide | <t>In mobile networks, mobility systems provide connectivity over a | |||
connectivity over a wireless link to stationary and non-stationary nodes | wireless link to stationary and non-stationary nodes. The user plane | |||
. | establishes a tunnel between the mobile node and its anchor node over | |||
The user-plane establishes a tunnel between the mobile node and its anch | IP-based backhaul and core networks. </t> | |||
or | <t>This document specifies the applicability of SRv6 <xref | |||
node over IP-based backhaul and core networks. </t> | target="RFC8754" format="default"/> <xref target="RFC8986" | |||
<t> This document specifies the applicability of SRv6 (Segment | format="default"/> to mobile networks. </t> | |||
Routing IPv6) <xref target="RFC8754" format="default"/><xref target="RFC | ||||
8986" format="default"/> to mobile networks. </t> | <t>Segment Routing (SR) <xref target="RFC8402" format="default"/> is a | |||
<t>Segment Routing <xref target="RFC8402" format="default"/> is a source r | source-routing architecture: a node steers a packet through an ordered | |||
outing architecture: a node steers a packet through an ordered list of instructi | list of instructions called "segments". A segment can represent any | |||
ons called "segments". A segment can represent any instruction, topological or s | instruction, topological or service based.</t> | |||
ervice based.</t> | <t>SRv6 applied to mobile networks enables a mobile architecture based | |||
<t>SRv6 applied to mobile networks enables a source-routing based | on source routing, where operators can explicitly indicate a route for | |||
mobile architecture, where operators can explicitly indicate a route | the packets to and from the mobile node. The SRv6 Endpoint nodes serve | |||
for the packets to and from the mobile node. The SRv6 Endpoint nodes | as mobile user-plane anchors.</t> | |||
serve as mobile user-plane anchors.</t> | ||||
</section> | </section> | |||
<!-- End section "Introduction" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Conventions and Terminology</name> | <name>Conventions and Terminology</name> | |||
<t> | <t> | |||
The key words "MUST", "MUST NOT", | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
"RECOMMENDED", "NOT RECOMMENDED", | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
"MAY", and "OPTIONAL" in this document are | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
to be interpreted as described in BCP 14 <xref target="RFC2119" format=" | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are | |||
default"/> | to be interpreted as described in BCP 14 <xref target="RFC2119"/> | |||
<xref target="RFC8174" format="default"/> when, and only when, they ap | <xref target="RFC8174"/> when, and only when, they appear in all capitals, | |||
pear in all capitals, as shown here. | as shown here. | |||
</t> | </t> | |||
<section anchor="terms" numbered="true" toc="default"> | <section anchor="terms" numbered="true" toc="default"> | |||
<name>Terminology</name> | <name>Terminology</name> | |||
<ul spacing="compact"> | <dl spacing="normal" newline="false"> | |||
<li>CNF: Cloud-native Network Function</li> | <dt>CNF:</dt> <dd>Cloud-native Network Function</dd> | |||
<li>NFV: Network Function Virtualization </li> | <dt>NFV:</dt> <dd>Network Function Virtualization </dd> | |||
<li>PDU: Packet Data Unit</li> | <dt>PDU:</dt> <dd>Packet Data Unit</dd> | |||
<li>PDU Session: Context of a UE connected to a mobile network.</li> | <dt>PDU Session:</dt> <dd>Context of a UE connected to a mobile | |||
<li>UE: User Equipment</li> | network</dd> | |||
<li>gNB: gNodeB <xref target="TS.23501" format="default"/></li> | <dt>UE:</dt> <dd>User Equipment</dd> | |||
<li>UPF: User Plane Function </li> | <dt>gNB:</dt> <dd>gNodeB <xref target="TS.23501" | |||
<li>VNF: Virtual Network Function</li> | format="default"/></dd> | |||
<li>DN: Data Network</li> | <dt>UPF:</dt> <dd>User Plane Function </dd> | |||
<li>Uplink: from the UE towards the DN</li> | <dt>VNF:</dt> <dd>Virtual Network Function</dd> | |||
<li>Downlink: from the DN towards the UE</li> | <dt>DN:</dt> <dd>Data Network</dd> | |||
</ul> | <dt>Uplink:</dt> <dd>from the UE towards the DN</dd> | |||
<t>The following terms used within this document are defined in | <dt>Downlink:</dt> <dd>from the DN towards the UE</dd> | |||
<xref target="RFC8402" format="default"/>: Segment Routing, SR Domai | </dl> | |||
n, Segment ID (SID), SRv6, SRv6 | <t>The following terms used within this document are defined in <xref | |||
SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Bindin | target="RFC8402" format="default"/>: Segment Routing, SR domain, | |||
g SID.</t> | Segment ID (SID), SRv6, SRv6 SID, Active Segment, SR Policy, and Binding | |||
<t> The following terms used within this document are defined in | SID (BSID).</t> | |||
<xref target="RFC8754" format="default"/>: SRH, SR Source Node, Tran | <t>The following terms used within this document are defined in <xref | |||
sit Node, SR Segment Endpoint | target="RFC8754" format="default"/>: Segment Routing Header (SRH) and Re | |||
Node and Reduced SRH.</t> | duced | |||
<t>The following terms used within this document are defined in <xref ta | SRH.</t> | |||
rget="RFC8986" format="default"/>: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 | ||||
Segment Endpoint Behavior.</t> | <t>The following terms used within this document are defined in <xref | |||
target="RFC8986" format="default"/>: NH (next header), SL (the Segments | ||||
Left field of the SRH), FIB (Forwarding Information Base), SA (Source | ||||
Address), DA (Destination Address), and SRv6 | ||||
Endpoint Behavior.</t> | ||||
</section> | </section> | |||
<!-- End subsection "Terminology" --> | ||||
<section anchor="conventions" numbered="true" toc="default"> | <section anchor="conventions" numbered="true" toc="default"> | |||
<name>Conventions</name> | <name>Conventions</name> | |||
<t>An SR Policy is resolved to a SID list. A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to v isit, and S3 is the last SID to visit along the SR path.</t> | <t>An SR Policy is resolved to a SID list. A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to v isit, and S3 is the last SID to visit along the SR path.</t> | |||
<t>(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:</t> | ||||
<ul spacing="compact"> | ||||
<li>Source Address is SA, Destination Address is DA, and next-header i | ||||
s SRH</li> | ||||
<li>SRH with SID list <S1, S2, S3> with Segments Left = SL</li> | ||||
<li>Note the difference between the <> and () symbols: <S1, S | ||||
2, S3> represents a SID list where S1 is the first SID and S3 is the last SID | ||||
to traverse. (S3, S2, S1; SL) represents the same SID list but encoded in the S | ||||
RH format where the rightmost SID in the SRH is the first SID and the leftmost S | ||||
ID in the SRH is the last SID. When referring to an SR policy in a high-level us | ||||
e-case, it is simpler to use the <S1, S2, S3> notation. When referring to | ||||
an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notation i | ||||
s more convenient.</li> | ||||
<li>The payload of the packet is omitted.</li> | ||||
</ul> | ||||
<t>(SA1,DA1) (SA2, DA2) represents an IPv6 packet with:</t> | ||||
<ul spacing="compact"> | ||||
<li>Source Address is SA1, Destination Address is DA1, and next-header | ||||
is IP</li> | ||||
<li>Source Address is SA2, Destination Address is DA2.</li> | ||||
</ul> | ||||
<t>Throughout the document the representation SRH[n] is used as shorter | ||||
representation of Segment List[n], as defined in <xref target="RFC8754" format=" | ||||
default"/>.</t> | ||||
<t>This document uses the following conventions throughout the different | <t>(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet where:</t> | |||
examples:</t> | <ul spacing="normal"> | |||
<ul spacing="compact"> | <li>Source Address is SA, Destination Address is DA, and | |||
<li> gNB::1 is an IPv6 address (SID) assigned to the gNB.</li> | next header is SRH</li> | |||
<li> U1::1 is an IPv6 address (SID) assigned to UPF1.</li> | <li><t>SRH with SID list <S1, S2, S3> with Segments Left = | |||
<li> U2::1 is an IPv6 address (SID) assigned to UPF2.</li> | SL</t> | |||
<li> U2:: is the Locator of UPF2.</li> | ||||
<t>Note the difference between the <> and () | ||||
symbols. <S1, S2, S3> represents a SID list where S1 is the | ||||
first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) | ||||
represents the same SID list but encoded in the SRH format where | ||||
the rightmost SID in the SRH is the first SID and the leftmost | ||||
SID in the SRH is the last SID. When referring to an SR Policy | ||||
in a high-level use case, it is simpler to use the <S1, S2, | ||||
S3> notation. When referring to an illustration of the | ||||
detailed packet behavior, the (S3, S2, S1; SL) notation is more | ||||
convenient.</t> | ||||
</li> | ||||
<li>The payload of the packet is omitted.</li> | ||||
</ul> | ||||
<t>(SA1,DA1) (SA2, DA2) represents an IPv6 packet where:</t> | ||||
<ul spacing="normal"> | ||||
<li>Source Address is SA1, Destination Address is DA1, and | ||||
next header is IP.</li> | ||||
<li>Source Address is SA2, and Destination Address is DA2.</li> | ||||
</ul> | ||||
<t>Throughout the document, the representation SRH[n] is used as a | ||||
shorter representation of Segment List[n], as defined in <xref | ||||
target="RFC8754" format="default"/>.</t> | ||||
<t>This document uses the following conventions throughout the | ||||
different examples:</t> | ||||
<ul spacing="normal"> | ||||
<li>gNB::1 is an IPv6 address (SID) assigned to the gNB.</li> | ||||
<li>U1::1 is an IPv6 address (SID) assigned to UPF1.</li> | ||||
<li>U2::1 is an IPv6 address (SID) assigned to UPF2.</li> | ||||
<li>U2:: is the Locator of UPF2.</li> | ||||
</ul> | </ul> | |||
</section> | </section> | |||
<!-- End subsection "Conventions" --> | ||||
<section anchor="srv6-funcs" numbered="true" toc="default"> | <section anchor="srv6-funcs" numbered="true" toc="default"> | |||
<name>Predefined SRv6 Endpoint Behaviors</name> | <name>Predefined SRv6 Endpoint Behaviors</name> | |||
<t> | ||||
The following SRv6 Endpoint Behaviors are defined in | <t> | |||
The following SRv6 Endpoint Behaviors are used throughout this docume | ||||
nt. They are defined in | ||||
<xref target="RFC8986" format="default"/>. | <xref target="RFC8986" format="default"/>. | |||
</t> | </t> | |||
<ul spacing="compact"> | <ul spacing="normal"> | |||
<li> End.DT4: Decapsulation and Specific IPv4 Table Lookup</li> | <li>End.DT4: Decapsulation and Specific IPv4 Table Lookup</li> | |||
<li> End.DT6: Decapsulation and Specific IPv6 Table Lookup</li> | <li>End.DT6: Decapsulation and Specific IPv6 Table Lookup</li> | |||
<li> End.DT46: Decapsulation and Specific IP Table Lookup</li> | <li>End.DT46: Decapsulation and Specific IP Table Lookup</li> | |||
<li> End.DX4: Decapsulation and IPv4 Cross-Connect</li> | <li>End.DX4: Decapsulation and IPv4 Cross-Connect</li> | |||
<li> End.DX6: Decapsulation and IPv6 Cross-Connect</li> | <li>End.DX6: Decapsulation and IPv6 Cross-Connect</li> | |||
<li> End.DX2: Decapsulation and L2 Cross-Connect</li> | <li>End.DX2: Decapsulation and L2 Cross-Connect</li> | |||
<li> End.T: Endpoint with specific IPv6 Table Lookup</li> | <li>End.T: Endpoint with specific IPv6 Table Lookup</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
This document defines new SRv6 Segment Endpoint Behaviors in <xref ta rget="srv6_functions" format="default"/>.</t> | This document defines new SRv6 Endpoint Behaviors in <xref target="sr v6_functions" format="default"/>.</t> | |||
</section> | </section> | |||
<!-- End section "Predefined SRv6 Functions" --> | ||||
</section> | </section> | |||
<!-- End section "Conventions and Terminology" --> | ||||
<section anchor="motivations" numbered="true" toc="default"> | <section anchor="motivations" numbered="true" toc="default"> | |||
<name>Motivation</name> | <name>Motivation</name> | |||
<t> Mobile networks are becoming more challenging to operate. | <t> Mobile networks are becoming more challenging to operate. On one | |||
On one hand, traffic is constantly growing, and latency requirements | hand, traffic is constantly growing, and latency requirements are | |||
are tighter; on the other-hand, there are new use-cases like | tighter; on the other hand, there are new use cases like distributed NFV | |||
distributed NFV Infrastructure that are also challenging network operatio | Infrastructure that are also challenging network operations. On top of | |||
ns. On top of this, the number of devices connected is steadily growing, causing | this, the number of devices connected is steadily growing, causing | |||
scalability problems in mobile entities as the state to maintain keeps increasi | scalability problems in mobile entities as the state to maintain keeps | |||
ng.</t> | increasing.</t> | |||
<t> The current architecture of mobile networks does not take into account | ||||
the underlying transport. The user-plane is rigidly fragmented into | <t> The current architecture of mobile networks does not take into | |||
radio access, core and service networks, connected by tunneling | account the underlying transport. The user plane is rigidly fragmented | |||
according to user-plane roles such as access and anchor nodes. These | into radio access, core, and service networks that connected by tunneling | |||
factors have made it difficult for the operator | according to user-plane roles such as access and anchor nodes. These | |||
to optimize and operate the data-path. | factors have made it difficult for the operator to optimize and operate | |||
the data path. | ||||
</t> | </t> | |||
<t> In the meantime, | <t> In the meantime, | |||
applications have shifted to use IPv6, and network operators | applications have shifted to use IPv6, and network operators | |||
have started adopting IPv6 as their IP transport. | have started adopting IPv6 as their IP transport. | |||
SRv6, the IPv6 dataplane instantiation of Segment Routing | SRv6, the IPv6 data plane instantiation of Segment Routing | |||
<xref target="RFC8402" format="default"/>, integrates both | <xref target="RFC8402" format="default"/>, integrates both | |||
the application data-path and the underlying transport layer into | the application data path and the underlying transport layer into | |||
a single protocol, allowing operators to optimize the network in a | a single protocol, allowing operators to optimize the network in a | |||
simplified manner and removing forwarding state from the network. It is a lso | simplified manner and removing forwarding state from the network. It is a lso | |||
suitable for virtualized environments, like VNF/CNF to VNF/CNF networking. SRv | suitable for virtualized environments, like VNF/CNF-to-VNF/CNF networking. SRv | |||
6 has been deployed in dozens of networks <xref target="I-D.matsushima-spring-sr | 6 has been deployed in dozens of networks <xref target="I-D.matsushima-spring-sr | |||
v6-deployment-status" format="default"/>.</t> | v6-deployment-status" format="default"/>.</t> | |||
<t> SRv6 defines the network-programming concept <xref target="RFC8986" fo | <t> SRv6 defines the network programming concept <xref target="RFC8986" fo | |||
rmat="default"/>. | rmat="default"/>. | |||
Applied to mobility, SRv6 can provide the user-plane behaviors needed | Applied to mobility, SRv6 can provide the user-plane behaviors needed | |||
for mobility management. SRv6 takes advantage of the underlying transport | for mobility management. SRv6 takes advantage of the underlying transport | |||
awareness and flexibility together with the ability to also include services t | awareness and flexibility together with the ability to also include services t | |||
o optimize the end-to-end mobile dataplane.</t> | o optimize the end-to-end mobile data plane.</t> | |||
<t>The use-cases for SRv6 mobility are discussed in <xref target="I-D.cama | <t>The use cases for SRv6 mobility are discussed in <xref target="I-D.cama | |||
rilloelmalky-springdmm-srv6-mob-usecases" format="default"/>, and the architectu | rilloelmalky-springdmm-srv6-mob-usecases" format="default"/>, and the architectu | |||
ral benefits are discussed in <xref target="I-D.kohno-dmm-srv6mob-arch" />. </t> | ral benefits are discussed in <xref target="I-D.kohno-dmm-srv6mob-arch" />. </t> | |||
</section> | </section> | |||
<!-- End section "Motivation" --> | ||||
<section anchor="scenarios" numbered="true" toc="default"> | <section anchor="scenarios" numbered="true" toc="default"> | |||
<name>3GPP Reference Architecture</name> | <name>3GPP Reference Architecture</name> | |||
<t> This section presents the 3GPP Reference Architecture and possible dep loyment | <t> This section presents the 3GPP reference architecture and possible dep loyment | |||
scenarios.</t> | scenarios.</t> | |||
<t> <xref target="fig_5g-ref-arch" format="default"/> shows a reference di agram from | <t> <xref target="fig_5g-ref-arch" format="default"/> shows a reference di agram from | |||
the 5G packet core architecture <xref target="TS.23501" format="default" />.</t> | the 5G packet core architecture <xref target="TS.23501" format="default" />.</t> | |||
<t> The user plane described in this document does not depend on any | <t> The user plane described in this document does not depend on any | |||
specific architecture. The 5G packet core architecture as shown is | specific architecture. The 5G packet core architecture as shown is | |||
based on the 3GPP standards.</t> | based on the 3GPP standards.</t> | |||
<figure anchor="fig_5g-ref-arch"> | ||||
<name>3GPP 5G Reference Architecture</name> | <figure anchor="fig_5g-ref-arch"> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <name>3GPP 5G Reference Architecture</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+-----+ | +-----+ | |||
| AMF | | | AMF | | |||
/+-----+ | /+-----+ | |||
/ | [N11] | / | [N11] | |||
[N2] / +-----+ | [N2] / +-----+ | |||
+------/ | SMF | | +------/ | SMF | | |||
/ +-----+ | / +-----+ | |||
/ / \ | / / \ | |||
/ / \ [N4] | / / \ [N4] | |||
/ / \ ________ | / / \ ________ | |||
/ / \ / \ | / / \ / \ | |||
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | |||
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / | |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / | |||
+--+ +-----+ +------+ +------+ \________/ | +--+ +-----+ +------+ +------+ \________/ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<ul spacing="compact"> | ||||
<li>UE: User Equipment</li> | <dl spacing="normal" newline="false"> | |||
<li>gNB: gNodeB with N3 interface towards packet core (and N2 for contro | <dt>UE:</dt> | |||
l plane)</li> | <dd>User Equipment</dd> | |||
<li>UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)</li> | <dt>gNB:</dt> | |||
<li>UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane)</li> | <dd>gNodeB with N3 interface towards packet core (and N2 for control | |||
<li>SMF: Session Management Function </li> | plane)</dd> | |||
<li>AMF: Access and Mobility Management Function </li> | <dt>UPF1:</dt> | |||
<li>DN: Data Network e.g., operator services, Internet access </li> | <dd>UPF with Interfaces N3 and N9 (and N4 for control plane)</dd> | |||
</ul> | <dt>UPF2:</dt> | |||
<dd>UPF with Interfaces N9 and N6 (and N4 for control plane)</dd> | ||||
<dt>SMF:</dt> | ||||
<dd>Session Management Function</dd> | ||||
<dt>AMF:</dt> | ||||
<dd>Access and Mobility Management Function</dd> | ||||
<dt>DN:</dt> | ||||
<dd>Data Network, e.g., operator services and Internet access </dd> | ||||
</dl> | ||||
<t> This reference diagram does not depict a UPF that is only connected | <t> This reference diagram does not depict a UPF that is only connected | |||
to N9 interfaces, although the mechanisms defined in this document | to N9 interfaces, although the mechanisms defined in this document | |||
also work in such a case.</t> | also work in such a case.</t> | |||
<t> Each session from a UE gets assigned to a UPF. Sometimes multiple | <t> Each session from a UE gets assigned to a UPF. Sometimes multiple | |||
UPFs may be used, providing richer service functions. A UE gets its | UPFs may be used, providing richer service functions. A UE gets its | |||
IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. | IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. The UPF | |||
The UPF advertises that IP address block toward the Internet, | advertises that IP address block toward the Internet, ensuring that | |||
ensuring that return traffic is routed to the right UPF. </t> | return traffic is routed to the right UPF. </t> | |||
</section> | </section> | |||
<!-- End section "A 3GPP Reference Architecture" --> | ||||
<section anchor="uplane-functions" numbered="true" toc="default"> | <section anchor="uplane-functions" numbered="true" toc="default"> | |||
<name>User-plane modes</name> | <name>User-Plane Modes</name> | |||
<t>This section introduces an SRv6 based mobile user-plane.It presents two | <t>This section introduces an SRv6-based mobile user plane. It presents | |||
different | two different "modes" that vary with respect to the use of SRv6.</t> | |||
"modes" that vary with respect to the use of SRv6. | <t>The first mode is the "Traditional mode", which inherits the current | |||
The first one is the "Traditional mode", which inherits the | 3GPP mobile architecture. In this mode, the <xref target="TS.29281" | |||
current 3GPP mobile architecture. In this mode | format="default">GTP-U protocol</xref> is replaced by SRv6. However, the | |||
<xref target="TS.29281" format="default">GTP-U protocol</xref> is replace | N3, N9, and N6 interfaces are still point-to-point interfaces with no | |||
d by SRv6, however the N3, N9 and N6 interfaces are still point-to-point interfa | intermediate waypoints as in the current mobile network | |||
ces with no intermediate waypoints as in the current mobile network architecture | architecture.</t> | |||
.</t> | <t> The second mode is the "Enhanced mode". This is an evolution from | |||
<t> The second mode is the "Enhanced mode". | the "Traditional mode". In this mode, the N3, N9, or N6 interfaces have | |||
This is an evolution from the "Traditional mode". In this mode the N3, N9 | intermediate waypoints (SIDs) that are used for traffic engineering or | |||
or N6 interfaces have intermediate waypoints -SIDs- that are used for Traffic En | VNF purposes transparent to 3GPP functionalities. This results in | |||
gineering or VNF purposes transparent to 3GPP functionalities. This results in o | optimal end-to-end policies across the mobile network with transport and | |||
ptimal end-to-end policies across the mobile network with transport and services | services awareness.</t> | |||
awareness.</t> | <t>In both the Traditional and the Enhanced modes, this document assumes | |||
<t>In both, the Traditional and the Enhanced modes, this document assumes | that the gNB as well as the UPFs are SR-aware (N3, N9, and potentially | |||
that the | N6 interfaces are SRv6).</t> | |||
gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 | <t>In addition to those two modes, this document introduces three | |||
interfaces are SRv6).</t> | mechanisms for interworking with legacy access networks (those where the | |||
<t>In addition to those two modes, this document introduces three mechanis | N3 interface is unmodified). In this document, they are introduced as a | |||
ms for interworking with legacy | variant to the Enhanced mode, but they are equally applicable to the | |||
access networks (those where the N3 interface is unmodified). In this docume | Traditional mode.</t> | |||
nt they are introduced as a variant to the Enhanced mode, however they are equal | ||||
ly applicable to the Traditional mode.</t> | ||||
<t>One of these mechanisms is designed to interwork with legacy gNBs | <t>One of these mechanisms is designed to interwork with legacy gNBs | |||
using GTP-U/IPv4. The second mechanism is designed to interwork with | using GTP-U/IPv4. The second mechanism is designed to interwork with | |||
legacy gNBs using GTP-U/IPv6. The third of those mechanisms is another mo | legacy gNBs using GTP-U/IPv6. The third mechanism is another mode that | |||
de that allows deploying SRv6 when legacy gNBs and UPFs that still run GTP-U.</t | allows deploying SRv6 when legacy gNBs and UPFs still run GTP-U.</t> | |||
> | <t> This document uses the SRv6 Endpoint Behaviors defined in | |||
<t> This document uses SRv6 Segment Endpoint Behaviors defined in | <xref target="RFC8986" format="default"/> as well as the new SRv6 | |||
<xref target="RFC8986" format="default"/> as well | Endpoint Behaviors designed for the mobile user plane that are | |||
as new SRv6 Segment Endpoint Behaviors designed for the mobile user plane | defined in <xref target="srv6_functions" format="default"/> of this | |||
that are defined in this document in <xref target="srv6_functions" format="defa | document. | |||
ult"/>. | ||||
</t> | </t> | |||
<section anchor="traditional_mode" numbered="true" toc="default"> | <section anchor="traditional_mode" numbered="true" toc="default"> | |||
<name>Traditional mode</name> | <name>Traditional Mode</name> | |||
<t> In the traditional mode, the existing mobile UPFs remain unchanged | <t> In the Traditional mode, the existing mobile UPFs remain unchanged | |||
with the sole exception of the use of SRv6 as the data | with the sole exception of the use of SRv6 as the data plane instead | |||
plane instead of GTP-U. There is no impact to the rest of the | of GTP-U. There is no impact to the rest of the mobile system.</t> | |||
mobile system.</t> | ||||
<t> In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 | <t> In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 | |||
with a specific GTP-U tunnel (Tunnel Endpoint Identifier - TEID). Thi | with a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)). This | |||
s 1-for-1 mapping is | 1-for-1 mapping is mirrored here to replace GTP-U encapsulation with | |||
mirrored here to replace GTP-U encapsulation with the SRv6 | the SRv6 encapsulation, while not changing anything else. There will | |||
encapsulation, while not changing anything else. There will be a uniq | be a unique SRv6 SID associated with each PDU Session, and the SID | |||
ue SRv6 SID | list only contains a single SID.</t> | |||
associated with each PDU Session, and the SID list only contains a si | <t> The Traditional mode minimizes the required changes to the mobile | |||
ngle SID.</t> | system; hence, it is a good starting point for forming common | |||
<t> The traditional mode minimizes the changes required to the mobile | ground.</t> | |||
system; hence it is a good starting point for forming a common ground | <t> The gNB/UPF control plane (N2/N4 interface) is unchanged; | |||
.</t> | specifically, a single IPv6 address is provided to the gNB. The same | |||
<t> The gNB/UPF control-plane (N2/N4 interface) is unchanged, specifical | control plane signaling is used, and the gNB/UPF decides to use SRv6 | |||
ly | based on signaled GTP-U parameters per local policy. The only | |||
a single IPv6 address is provided to the gNB. The same control plane signa | information from the GTP-U parameters used for the SRv6 policy is the | |||
lling | TEID, QFI (QoS Flow Identifier), and the IPv6 Destination Address.</t> | |||
is used, and the gNB/UPF decides to use SRv6 based on signaled GTP-U param | <t> Our example topology is shown in <xref target="fig_traditional" | |||
eters per local policy. The only information from the GTP-U parameters used for | format="default"/>. The gNB and the UPFs are SR-aware. In the | |||
the SRv6 policy is the TEID, QFI -QoS Flow Identifier-, and the IPv6 Destination | descriptions of the uplink and downlink packet flow, A is an IPv6 | |||
Address.</t> | address of the UE, and Z is an IPv6 address reachable within the DN. | |||
<t> Our example topology is shown in <xref target="fig_traditional" form | End.MAP, a new SRv6 Endpoint Behavior defined in <xref | |||
at="default"/>. | target="end-map-function" format="default"/>, is used.</t> | |||
The gNB and the UPFs are SR-aware. | ||||
In the descriptions of the uplink and downlink packet flow, | <figure anchor="fig_traditional"> | |||
A is an IPv6 address of the UE, and Z is an IPv6 address reachable | <name>Traditional Mode - Example Topology</name> | |||
within the Data Network DN. A new SRv6 Endpoint Behavior, End.MAP, d | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
efined | ||||
in <xref target="end-map-function" format="default"/>, is used.</t> | ||||
<figure anchor="fig_traditional"> | ||||
<name>Traditional mode - example topology</name> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
________ | ________ | |||
SRv6 SRv6 / \ | SRv6 SRv6 / \ | |||
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | |||
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / | |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / | |||
+--+ +-----+ +------+ +------+ \________/ | +--+ +-----+ +------+ +------+ \________/ | |||
SRv6 node SRv6 node SRv6 node | SRv6 node SRv6 node SRv6 node | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="traditional_up" numbered="true" toc="default"> | <section anchor="traditional_up" numbered="true" toc="default"> | |||
<name>Packet flow - Uplink</name> | <name>Packet Flow - Uplink</name> | |||
<t> The uplink packet flow is as follows:</t> | <t> The uplink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UE_out : (A,Z) | UE_out : (A,Z) | |||
gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1> | gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1> | |||
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP | UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP | |||
UPF2_out: (A,Z) -> End.DT4 or End.DT6]]></artwork> | UPF2_out: (A,Z) -> End.DT4 or End.DT6 | |||
<t> When the UE packet arrives at the gNB, the gNB performs a | ]]></artwork> | |||
H.Encaps.Red operation. Since there is only one SID, | ||||
there is no need to push an SRH (reduced SRH). gNB only adds an out | <t> When the UE packet arrives at the gNB, the gNB performs an | |||
er IPv6 | H.Encaps.Red operation. Since there is only one SID, there is no | |||
header with IPv6 DA U1::1. gNB obtains the SID | need to push an SRH (reduced SRH). gNB only adds an outer IPv6 | |||
U1::1 from the existing control plane (N2 interface). U1::1 represe | header with IPv6 DA U1::1. gNB obtains the SID U1::1 from the | |||
nts an anchoring | existing control plane (N2 interface). U1::1 represents an anchoring | |||
SID specific for that session at UPF1.</t> | SID specific for that session at UPF1.</t> | |||
<t> When the packet arrives at UPF1, the SID U1::1 is associated with | <t> When the packet arrives at UPF1, the SID U1::1 is associated | |||
the End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, that | with the End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 with | |||
belongs to the next UPF (U2).</t> | U2::1, which belongs to the next UPF (U2).</t> | |||
<t> When the packet arrives at UPF2, the SID U2::1 corresponds to | <t> When the packet arrives at UPF2, the SID U2::1 corresponds to an | |||
an End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulat | End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates | |||
es the packet, performs a | the packet, performs a lookup in a specific table associated with | |||
lookup in a specific table associated with that mobile network and | that mobile network, and forwards the packet toward the DN.</t> | |||
forwards the packet toward the data network (DN).</t> | ||||
</section> | </section> | |||
<!-- End section "Packet flow - Uplink" --> | ||||
<section anchor="traditional_dn" numbered="true" toc="default"> | <section anchor="traditional_dn" numbered="true" toc="default"> | |||
<name>Packet flow - Downlink</name> | <name>Packet Flow - Downlink</name> | |||
<t>The downlink packet flow is as follows:</t> | <t>The downlink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UPF2_in : (Z,A) | UPF2_in : (Z,A) | |||
UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2> | UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2> | |||
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP | UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP | |||
gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 | gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 | |||
]]></artwork> | ]]></artwork> | |||
<t> When the packet arrives at the UPF2, the UPF2 maps that flow into | ||||
a PDU Session. This PDU Session is associated with the segment | <t> When the packet arrives at the UPF2, the UPF2 maps that flow | |||
endpoint <U1::2>. UPF2 performs | into a PDU Session. This PDU Session is associated with the segment | |||
a H.Encaps.Red operation, encapsulating the packet into | endpoint <U1::2>. UPF2 performs an H.Encaps.Red operation, | |||
a new IPv6 header with no SRH since there is only one SID.</t> | encapsulating the packet into a new IPv6 header with no SRH since | |||
<t> Upon packet arrival on UPF1, the SID U1::2 is a local SID associat | there is only one SID.</t> | |||
ed with the End.MAP | <t> Upon packet arrival on UPF1, the SID U1::2 is a local SID | |||
SRv6 Endpoint Behavior. It maps the SID to the next anchoring | associated with the End.MAP SRv6 Endpoint Behavior. It maps the SID | |||
point and replaces U1::2 by gNB::1, that belongs to the next | to the next anchoring point and replaces U1::2 with gNB::1, which | |||
hop.</t> | belongs to the next hop.</t> | |||
<t> Upon packet arrival on gNB, the SID gNB::1 corresponds to an | <t> Upon packet arrival on gNB, the SID gNB::1 corresponds to an | |||
End.DX4, End.DX6 or End.DX2 behavior (depending on the PDU Session | End.DX4, End.DX6, or End.DX2 behavior (depending on the PDU Session | |||
Type). The gNB decapsulates the packet, | Type). The gNB decapsulates the packet, removing the IPv6 header and | |||
removing the IPv6 header and all its extensions headers, and | all its extensions headers, and forwards the traffic toward the | |||
forwards the traffic toward the UE.</t> | UE.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Downlink" --> | ||||
</section> | </section> | |||
<!-- End section "Traditional mode" --> | ||||
<section anchor="enhanced_mode" numbered="true" toc="default"> | <section anchor="enhanced_mode" numbered="true" toc="default"> | |||
<name>Enhanced mode</name> | <name>Enhanced Mode</name> | |||
<t> Enhanced mode improves scalability, provides traffic engineering cap | <t> Enhanced mode improves scalability, provides traffic engineering | |||
abilities, and allows service | capabilities, and allows service programming <xref | |||
programming <xref target="I-D.ietf-spring-sr-service-programming" for | target="I-D.ietf-spring-sr-service-programming" format="default"/>, | |||
mat="default"/>, | thanks to the use of multiple SIDs in the SID list (instead of a | |||
thanks to the use of multiple SIDs in the SID list (instead of a dire | direct connectivity in between UPFs with no intermediate waypoints as | |||
ct connectivity in between UPFs with no intermediate waypoints as in Traditional | in Traditional mode).</t> | |||
Mode).</t> | <t>Thus, the main difference is that the SR Policy <bcp14>MAY</bcp14> | |||
<t>Thus, the main difference is that the SR policy MAY | include SIDs for traffic engineering and service programming in | |||
include SIDs for traffic engineering and service programming | addition to the anchoring SIDs at UPFs.</t> | |||
in addition to the anchoring SIDs at UPFs.</t> | <t>Additionally, in this mode, the operator may choose to aggregate | |||
<t>Additionally in this mode the operator may choose to aggregate severa | several devices under the same SID list (e.g., stationary residential | |||
l devices under the same SID list (e.g., stationary residential meters [water/en | meters (water and energy) connected to the same cell) to improve | |||
ergy] connected to the same cell) to improve scalability.</t> | scalability.</t> | |||
<t>The gNB/UPF control-plane (N2/N4 interface) is unchanged, specificall | <t>The gNB/UPF control plane (N2/N4 interface) is unchanged; | |||
y | specifically, a single IPv6 address is provided to the gNB. A local | |||
a single IPv6 address is provided to the gNB. A local policy instruct | policy instructs the gNB to use SRv6.</t> | |||
s the gNB to use SRv6.</t> | <t> The gNB resolves the IP address received via the control plane | |||
<t> The gNB resolves the IP address received via the control plane into | into a SID list. The resolution mechanism is out of the scope of this | |||
a SID list. The resolution mechanism is out of the scope of this document.</t> | document.</t> | |||
<t> Note that the SIDs MAY use the arguments <xref target="arguments-for | <t> Note that the SIDs <bcp14>MAY</bcp14> use the argument <xref | |||
-mobility" format="default">Args.Mob.Session </xref> if | target="arguments-for-mobility" format="default">Args.Mob.Session | |||
required by the UPFs.</t> | </xref> if required by the UPFs.</t> | |||
<t> <xref target="fig_enhanced" format="default"/> shows an Enhanced mod | <t> <xref target="fig_enhanced" format="default"/> shows an Enhanced | |||
e topology. | mode topology. The gNB and the UPF are SR-aware. The figure | |||
The gNB and the UPF are SR-aware. | shows two service segments, | |||
The Figure shows two service segments, S1 and C1. | S1 and C1. S1 represents a VNF in the network, and C1 | |||
S1 represents a VNF in the network, and C1 represents an intermediate | represents an intermediate router used for traffic engineering | |||
router used for Traffic Engineering purposes to enforce a low-latency path in t | purposes to enforce a low-latency path in the network. Note that | |||
he network. | neither S1 nor C1 are required to have an N4 interface.</t> | |||
Note that neither S1 nor C1 are required to have an N4 interface.</t> | ||||
<figure anchor="fig_enhanced"> | <figure anchor="fig_enhanced"> | |||
<name>Enhanced mode - Example topology</name> | <name>Enhanced Mode - Example Topology</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
+----+ SRv6 _______ | +----+ SRv6 _______ | |||
SRv6 --| C1 |--[N3] / \ | SRv6 --| C1 |--[N3] / \ | |||
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ | +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ | |||
|UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / | |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / | |||
+--+ +-----+ \ [N3]/ TE +------+ \_______/ | +--+ +-----+ \ [N3]/ TE +------+ \_______/ | |||
SRv6 node \ +----+ / SRv6 node | SRv6 node \ +----+ / SRv6 node | |||
-| S1 |- | -| S1 |- | |||
+----+ | +----+ | |||
SRv6 node | SRv6 node | |||
VNF | VNF | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="enhanced_uplink" numbered="true" toc="default"> | <section anchor="enhanced_uplink" numbered="true" toc="default"> | |||
<name>Packet flow - Uplink</name> | <name>Packet Flow - Uplink</name> | |||
<t>The uplink packet flow is as follows:</t> | <t>The uplink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UE_out : (A,Z) | UE_out : (A,Z) | |||
gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1> | gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1> | |||
S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z) | S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z) | |||
C1_out : (gNB, U1::1)(A,Z) ->End with PSP | C1_out : (gNB, U1::1)(A,Z) ->End with PSP | |||
UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U | UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U | |||
]]></artwork> | ]]></artwork> | |||
<t> UE sends its packet (A,Z) on a specific bearer to its gNB. | ||||
gNB's control plane associates that session from the UE(A) with | <t> UE sends its packet (A,Z) on a specific bearer to its | |||
the IPv6 address B. gNB resolves B into a SID list. | gNB. gNB's control plane associates that session from the UE(A) | |||
<S1, C1, U1::1>. </t> | with the IPv6 address B. gNB resolves B into a SID list <S1, | |||
C1, U1::1>. </t> | ||||
<t> When gNB transmits the packet, it contains all the segments of | <t> When gNB transmits the packet, it contains all the segments of | |||
the SR policy. The SR policy includes segments for | the SR Policy. The SR Policy includes segments for traffic | |||
traffic engineering (C1) and for service programming (S1). </t> | engineering (C1) and for service programming (S1). </t> | |||
<t> Nodes S1 and C1 perform their related Endpoint functionality | <t> Nodes S1 and C1 perform their related Endpoint functionality and | |||
and forward the packet. The End with PSP functionality referes to t | forward the packet. The "End with PSP" functionality refers to the | |||
he Endpoint behavior with Penultimate Segment Popping as defined in RFC8986.</t> | Endpoint Behavior with Penultimate Segment Popping as defined in | |||
<t> When the packet arrives at UPF1, the active segment (U1::1) is | <xref target="RFC8986" format="default"/>.</t> | |||
an End.DT4/End.DT6/End.DT2U which performs the decapsulation (remov | <t> When the packet arrives at UPF1, the active segment (U1::1) is an | |||
ing the | End.DT4/End.DT6/End.DT2U, which performs the | |||
IPv6 header with all its extension headers) and forwards toward | decapsulation (removing the IPv6 header with all its extension | |||
the data network.</t> | headers) and forwards toward the DN.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Uplink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Packet flow - Downlink</name> | <name>Packet Flow - Downlink</name> | |||
<t>The downlink packet flow is as follows:</t> | <t>The downlink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UPF1_in : (Z,A) ->UPF1 maps the flow w/ | UPF1_in : (Z,A) ->UPF1 maps the flow w/ | |||
SID list <C1,S1, gNB> | SID list <C1,S1, gNB> | |||
UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red | UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red | |||
C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A) | C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A) | |||
S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP | S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP | |||
gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 | gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 | |||
]]></artwork> | ]]></artwork> | |||
<t>When the packet arrives at the UPF1, the UPF1 maps that | <t>When the packet arrives at the UPF1, the UPF1 maps that | |||
particular flow into a UE PDU Session. This UE PDU Session is assoc | particular flow into a UE PDU Session. This UE PDU Session is | |||
iated | associated with the policy <C1, S1, gNB>. The UPF1 performs a | |||
with the policy <C1, S1, gNB>. The UPF1 performs a | H.Encaps.Red operation, encapsulating the packet into a new IPv6 | |||
H.Encaps.Red operation, encapsulating the packet into a | header with its corresponding SRH.</t> | |||
new IPv6 header with its corresponding SRH.</t> | ||||
<t>The nodes C1 and S1 perform their related Endpoint processing.</t> | <t>The nodes C1 and S1 perform their related Endpoint processing.</t> | |||
<t>Once the packet arrives at the gNB, the IPv6 DA corresponds to | <t>Once the packet arrives at the gNB, the IPv6 DA corresponds to an | |||
an End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on th | End.DX4, End.DX6, or End.DX2 behavior at the gNB (depending on the | |||
e underlying traffic). | underlying traffic). The gNB decapsulates the packet, removing the | |||
The gNB decapsulates the packet, removing the IPv6 header, | IPv6 header, and forwards the traffic towards the UE. The SID gNB::1 | |||
and forwards the traffic | is one example of a SID associated to this service.</t> | |||
towards the UE. The SID gNB::1 is one example of a SID associated t | <t>Note that there are several means to provide the UE session | |||
o this service.</t> | aggregation. The decision about which one to use is a local decision | |||
<t>Note that there are several means to provide the UE session aggrega | made by the operator. One option is to use <xref | |||
tion. The decision on which one to use is a local decision made by the operator. | target="arguments-for-mobility" format="default">Args.Mob.Session | |||
One option is to use the <xref target="arguments-for-mobility" format="default" | </xref>. Another option comprises the gNB performing an IP lookup on | |||
>Args.Mob.Session </xref>. Another option comprises the gNB performing an IP loo | the inner packet by using the End.DT4, End.DT6, and End.DT2U | |||
kup on the inner packet by using the End.DT4, End.DT6, and End.DT2U behaviors.</ | behaviors.</t> | |||
t> | ||||
</section> | </section> | |||
<!-- End section "Packet flow - Downlink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Scalability</name> | <name>Scalability</name> | |||
<t>The Enhanced Mode improves scalability since it allows the aggregat | <t>The Enhanced mode improves scalability since it allows the | |||
ion | aggregation of several UEs under the same SID list. For example, in | |||
of several UEs under the same SID list. For example, in t | the case of stationary residential meters that are connected to the | |||
he | same cell, all such devices can share the same SID list. This | |||
case of stationary residential meters that are connected | improves scalability compared to Traditional mode (unique SID per | |||
to the same cell, all such devices can share the same SID | UE) and compared to GTP-U (TEID per UE).</t> | |||
list. | ||||
This improves scalability compared to Traditional Mode | ||||
(unique SID per UE) and compared to GTP-U (TEID per UE).< | ||||
/t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<!-- End section "Enhanced Mode" --> | ||||
<section anchor="enhanced_gtp" numbered="true" toc="default"> | <section anchor="enhanced_gtp" numbered="true" toc="default"> | |||
<name>Enhanced mode with unchanged gNB GTP-U behavior</name> | <name>Enhanced Mode with Unchanged gNB GTP-U Behavior</name> | |||
<t> This section describes two mechanisms for interworking with legacy | <t> This section describes two mechanisms for interworking with legacy | |||
gNBs that still use GTP-U: one for IPv4, and another for IPv6.</t> | gNBs that still use GTP-U: one for IPv4 and another for IPv6.</t> | |||
<t> In the interworking scenarios as illustrated in | <t> In the interworking scenarios illustrated in <xref | |||
<xref target="fig_interworking" format="default"/>, the gNB does not | target="fig_interworking" format="default"/>, the gNB does not support | |||
support SRv6. | SRv6. The gNB supports GTP-U encapsulation over IPv4 or IPv6. To | |||
The gNB supports GTP-U encapsulation over IPv4 or IPv6. To achieve | achieve interworking, an SR Gateway (SRGW) entity is added. The SRGW | |||
interworking, an SR Gateway (SRGW) entity is added. The SRGW is a new | is a new entity that maps the GTP-U traffic into SRv6. It is deployed | |||
entity that maps the GTP-U traffic into SRv6. It is deployed at the boundary of | at the boundary of the SR domain and performs the mapping | |||
the SR Domain and performs the mapping functionality for inbound/outbound traff | functionality for inbound and outbound traffic.</t> | |||
ic.</t> | ||||
<t> The SRGW is not an anchor point and maintains very little state. | <t> The SRGW is not an anchor point and maintains very little state. | |||
For this reason, | For this reason, | |||
both IPv4 and IPv6 methods scale to millions of UEs.</t> | both IPv4 and IPv6 methods scale to millions of UEs.</t> | |||
<figure anchor="fig_interworking"> | ||||
<name>Example topology for interworking</name> | <figure anchor="fig_interworking"> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <name>Example Topology for Interworking</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
_______ | _______ | |||
IP GTP-U SRv6 / \ | IP GTP-U SRv6 / \ | |||
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ | |||
|UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / | |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / | |||
+--+ +-----+ +------+ +------+ \_______/ | +--+ +-----+ +------+ +------+ \_______/ | |||
SR Gateway SRv6 node | SR Gateway SRv6 node | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Both of the mechanisms described in this section are applicable to ei | ||||
ther the Traditional Mode or the Enhanced Mode.</t> | <t>Both of the mechanisms described in this section are applicable to th | |||
e Traditional mode and the Enhanced mode.</t> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Interworking with IPv6 GTP-U</name> | <name>Interworking with IPv6 GTP-U</name> | |||
<t>In this interworking mode the gNB at the N3 interface uses GTP-U | <t>In this interworking mode, the gNB at the N3 interface uses GTP-U | |||
over IPv6.</t> | over IPv6.</t> | |||
<t>Key points: | <t>Key points: | |||
</t> | </t> | |||
<ul spacing="compact"> | <ul spacing="normal"> | |||
<li> The gNB is unchanged (control-plane or user-plane) and | <li> The gNB is unchanged (control plane or user plane) and | |||
encapsulates into GTP-U (N3 interface is not modified).</li> | encapsulates into GTP-U (N3 interface is not modified).</li> <li> | |||
<li> The 5G Control-Plane towards the gNB (N2 interface) is unmodifi | The 5G control plane towards the gNB (N2 interface) is unmodified, | |||
ed, though multiple UPF addresses need to be used - one IPv6 address (i.e. a BSI | though multiple UPF addresses need to be used. One IPv6 address | |||
D at the SRGW) is needed per <SLA, PDU session type>. The SRv6 SID is diff | (i.e., a BSID at the SRGW) is needed per <SLA, PDU Session | |||
erent depending on the required <SLA, PDU session type> combination.</li> | Type>. The SRv6 SID is different depending on the required | |||
<li> In the uplink, the SRGW removes GTP-U header, finds the SID lis | <SLA, PDU Session Type> combination.</li> | |||
t related to the IPv6 DA, | <li> In the uplink, the SRGW removes the GTP-U header, finds the | |||
and adds SRH with the SID list.</li> | SID list related to the IPv6 DA, and adds SRH with the SID | |||
list.</li> | ||||
<li> There is no state for the downlink at the SRGW.</li> | <li> There is no state for the downlink at the SRGW.</li> | |||
<li> There is simple state in the uplink at the SRGW; using | <li> There is simple state in the uplink at the SRGW; using | |||
Enhanced mode results in fewer SR policies on this node. | Enhanced mode results in fewer SR Policies on this node. An SR | |||
An SR policy is shared across UEs as long as they belong to the s | Policy is shared across UEs as long as they belong to the same | |||
ame context (i.e., tenant). A set of many different policies (i.e., different SL | context (i.e., tenant). A set of many different policies (i.e., | |||
As) increases the amount of state required.</li> | different SLAs) increases the amount of state required.</li> | |||
<li> When a packet from the UE leaves the gNB, it is SR-routed. | <li> When a packet from the UE leaves the gNB, it is SR-routed. | |||
This simplifies network slicing | This simplifies network slicing | |||
<xref target="I-D.ietf-lsr-flex-algo" format="default"/>.</li> | <xref target="RFC9350" format="default"/>.</li> | |||
<li> In the uplink, the SRv6 BSID steers traffic | <li> In the uplink, the SRv6 BSID steers traffic | |||
into an SR policy when it arrives at the SRGW.</li> | into an SR Policy when it arrives at the SRGW.</li> | |||
</ul> | </ul> | |||
<t> An example topology is shown in | <t> An example topology is shown in | |||
<xref target="fig_interworking_ipv6" format="default"/>.</t> | <xref target="fig_interworking_ipv6" format="default"/>.</t> | |||
<t> S1 and C1 are two service segments. | <t> S1 and C1 are two service segments. | |||
S1 represents a VNF in the network, and C1 represents a router | S1 represents a VNF in the network, and C1 represents a router | |||
configured for Traffic Engineering.</t> | configured for traffic engineering.</t> | |||
<figure anchor="fig_interworking_ipv6"> | ||||
<name>Enhanced mode with unchanged gNB IPv6/GTP-U behavior</name> | <figure anchor="fig_interworking_ipv6"> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <name>Enhanced Mode with Unchanged gNB IPv6/GTP-U Behavior</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+----+ | +----+ | |||
IPv6/GTP-U -| S1 |- ___ | IPv6/GTP-U -| S1 |- ___ | |||
+--+ +-----+ [N3] / +----+ \ / | +--+ +-----+ [N3] / +----+ \ / | |||
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / | |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / | |||
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN | +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN | |||
GTP-U \ +------+ / +----+ +------+ \___ | GTP-U \ +------+ / +----+ +------+ \___ | |||
-| SRGW |- SRv6 SRv6 | -| SRGW |- SRv6 SRv6 | |||
+------+ TE | +------+ TE | |||
SR Gateway | SR Gateway | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Packet flow - Uplink</name> | <name>Packet Flow - Uplink</name> | |||
<t>The uplink packet flow is as follows:</t> | <t>The uplink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UE_out : (A,Z) | UE_out : (A,Z) | |||
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified | gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified | |||
(IPv6/GTP) | (IPv6/GTP) | |||
SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D | SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D | |||
SID at the SRGW | SID at the SRGW | |||
S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z) | S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z) | |||
C1_out : (SRGW, U2::T)(A,Z) -> End with PSP | C1_out : (SRGW, U2::T)(A,Z) -> End with PSP | |||
UPF2_out: (A,Z) -> End.DT4 or End.DT6 | UPF2_out: (A,Z) -> End.DT4 or End.DT6 | |||
]]></artwork> | ]]></artwork> | |||
<t> The UE sends a packet destined to Z toward the gNB on a | <t> The UE sends a packet destined to Z toward the gNB on a | |||
specific bearer for that session. The gNB, which is unmodified, | specific bearer for that session. The gNB, which is unmodified, | |||
encapsulates the packet into IPv6, UDP, and GTP-U headers. | encapsulates the packet into IPv6, UDP, and GTP-U headers. The | |||
The IPv6 DA B, and the GTP-U TEID T are the ones received in the | IPv6 DA B and the GTP-U TEID T are the ones received in the N2 | |||
N2 interface.</t> | interface.</t> | |||
<t> The IPv6 address that was signaled over the N2 interface for | <t> The IPv6 address that was signaled over the N2 interface for | |||
that UE PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding | that UE PDU Session, B, is now the IPv6 DA. B is an SRv6 | |||
SID at the SRGW. Hence the packet is routed to the SRGW.</t> | Binding SID at the SRGW. Hence, the packet is routed to the | |||
<t> When the packet arrives at the SRGW, the SRGW identifies | SRGW.</t> | |||
B as an End.M.GTP6.D Binding SID | <t> When the packet arrives at the SRGW, the SRGW identifies B as | |||
(see <xref target="End-M-GTP6-D" format="default"/>). Hence, the | an End.M.GTP6.D Binding SID (see <xref target="End-M-GTP6-D" | |||
SRGW removes | format="default"/>). Hence, the SRGW removes the IPv6, UDP, and | |||
the IPv6, UDP, and GTP-U headers, and pushes an IPv6 | GTP-U headers and pushes an IPv6 header with its own SRH | |||
header with its own SRH containing the SIDs bound to the | containing the SIDs bound to the SR Policy associated with this | |||
SR policy associated with this BindingSID. There | Binding SID. There is at least one instance of the End.M.GTP6.D SID | |||
at least one instance of the End.M.GTP6.D SID per PDU type.</t> | per PDU type.</t> | |||
<t> S1 and C1 perform their related Endpoint functionality | <t> S1 and C1 perform their related Endpoint functionality and | |||
and forward the packet.</t> | forward the packet.</t> | |||
<t> When the packet arrives at UPF2, the active segment is (U2::T) | <t> When the packet arrives at UPF2, the active segment is (U2::T), | |||
which is bound to End.DT4/6. UPF2 then decapsulates | which is bound to End.DT4/6. UPF2 then decapsulates (removing the | |||
(removing the outer IPv6 header with all its extension headers) | outer IPv6 header with all its extension headers) and forwards the | |||
and forwards the packet toward the data network.</t> | packet toward the DN.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Uplink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Packet flow - Downlink</name> | <name>Packet Flow - Downlink</name> | |||
<t>The downlink packet flow is as follows:</t> | <t>The downlink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UPF2_in : (Z,A) -> UPF2 maps the flow with | UPF2_in : (Z,A) -> UPF2 maps the flow with | |||
<C1, S1, SRGW::TEID,gNB> | <C1, S1, SRGW::TEID,gNB> | |||
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red | UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red | |||
C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) | C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) | |||
S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) | S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) | |||
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E | SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E | |||
gNB_out : (Z,A) | gNB_out : (Z,A) | |||
]]></artwork> | ]]></artwork> | |||
<t> When a packet destined to A arrives at the UPF2, the UPF2 | <t> When a packet destined to A arrives at the UPF2, the UPF2 | |||
performs a lookup in the table associated to A and finds the | performs a lookup in the table associated to A and finds the | |||
SID list <C1, S1, SRGW::TEID, gNB>. The UPF2 performs | SID list <C1, S1, SRGW::TEID, gNB>. The UPF2 performs | |||
an H.Encaps.Red operation, encapsulating the packet into | an H.Encaps.Red operation, encapsulating the packet into | |||
a new IPv6 header with its corresponding SRH.</t> | a new IPv6 header with its corresponding SRH.</t> | |||
<t> C1 and S1 perform their related Endpoint processing.</t> | <t> C1 and S1 perform their related Endpoint processing.</t> | |||
<t> Once the packet arrives at the SRGW, the SRGW identifies the | <t> Once the packet arrives at the SRGW, the SRGW identifies the | |||
active SID as an End.M.GTP6.E function. The SRGW removes | active SID as an End.M.GTP6.E function. The SRGW removes | |||
the IPv6 header and all its extensions headers. The SRGW | the IPv6 header and all its extensions headers. The SRGW | |||
generates new IPv6, UDP, and GTP-U headers. The new IPv6 DA | generates new IPv6, UDP, and GTP-U headers. The new IPv6 DA | |||
is the gNB which is the last SID in the received SRH. | is the gNB, which is the last SID in the received SRH. | |||
The TEID in the generated GTP-U header is an argument of the | The TEID in the generated GTP-U header is also an argument of the | |||
received End.M.GTP6.E SID. The SRGW pushes the headers to | received End.M.GTP6.E SID. The SRGW pushes the headers to | |||
the packet and forwards the packet toward the gNB. There | the packet and forwards the packet toward the gNB. There | |||
is one instance of the End.M.GTP6.E SID per PDU type.</t> | is one instance of the End.M.GTP6.E SID per PDU type.</t> | |||
<t> Once the packet arrives at the gNB, the packet is a regular | <t> Once the packet arrives at the gNB, the packet is a regular | |||
IPv6/GTP-U packet. The gNB looks for the specific radio bearer | IPv6/GTP-U packet. The gNB looks for the specific radio bearer | |||
for that TEID and forwards it on the bearer. This gNB behavior | for that TEID and forwards it on the bearer. This gNB behavior | |||
is not modified from current and previous generations.</t> | is not modified from current and previous generations.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Downlink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Scalability</name> | <name>Scalability</name> | |||
<t> For the downlink traffic, the SRGW is stateless. All the state | ||||
is in the SRH pushed by the UPF2. The UPF2 must have the UE | <t> For downlink traffic, the SRGW is stateless. All the state | |||
states since it is the UE's session anchor point.</t> | is in the SRH pushed by the UPF2. The UPF2 must have the UE | |||
<t> For the uplink traffic, the state at the SRGW does not | state since it is the UE's session anchor point.</t> | |||
necessarily need to be unique per PDU Session; the SR policy | <t> For uplink traffic, the state at the SRGW does not | |||
can be shared among UEs. This enables more | necessarily need to be unique per PDU Session; the SR Policy can | |||
scalable SRGW deployments compared to a | be shared among UEs. This enables more scalable SRGW deployments | |||
solution holding millions of states, one or more per UE.</t> | compared to a solution holding millions of states, one or more per | |||
UE.</t> | ||||
</section> | </section> | |||
<!-- End section "Scalability" --> | ||||
</section> | </section> | |||
<!-- End section "Interworking with IPv6 GTP" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Interworking with IPv4 GTP-U</name> | <name>Interworking with IPv4 GTP-U</name> | |||
<t> In this interworking mode the gNB uses GTP | <t> In this interworking mode, the gNB uses GTP over IPv4 in the N3 | |||
over IPv4 in the N3 interface</t> | interface.</t> | |||
<t> Key points: | <t> Key points: | |||
</t> | </t> | |||
<ul spacing="compact"> | <ul spacing="normal"> | |||
<li> The gNB is unchanged and encapsulates packets into GTP-U | <li> The gNB is unchanged and encapsulates packets into GTP-U (the | |||
(the N3 interface is not modified).</li> | N3 interface is not modified).</li> | |||
<li>N2 signaling is not changed, though multiple UPF addresses need | <li>N2 signaling is not changed, though multiple UPF addresses | |||
to be provided - one for each PDU Session Type.</li> | need to be provided -- one for each PDU Session Type.</li> | |||
<li> In the uplink, traffic is classified by SRGW's | <li> In the uplink, traffic is classified by SRGW's classification | |||
classification engine and steered into an SR policy. | engine and steered into an SR Policy. The SRGW may be implemented | |||
The SRGW may be implemented in a UPF or as a separate entity. How | in a UPF or as a separate entity. How the classification engine | |||
the classification engine rules are set up is outside the scope of this documen | rules are set up is outside the scope of this document, though one | |||
t, though one example is using BGP signaling from a Mobile User Plane Controller | example is using BGP signaling from a Mobile User Plane (MUP) Contro | |||
<xref target="I-D.mhkk-dmm-srv6mup-architecture" format="default"/>.</li> | ller | |||
<li> SRGW removes GTP-U header, finds the SID list related to DA, an | <xref target="I-D.mhkk-dmm-srv6mup-architecture" | |||
d adds | format="default"/>.</li> | |||
an SRH with the SID list.</li> | <li> SRGW removes the GTP-U header, finds the SID list related to DA | |||
, | ||||
and adds an SRH with the SID list.</li> | ||||
</ul> | </ul> | |||
<t> An example topology is shown in | <t> An example topology is shown in <xref | |||
<xref target="fig_interworking_ipv4" format="default"/>. In this | target="fig_interworking_ipv4" format="default"/>. In this mode, the | |||
mode | gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As | |||
the gNB is an unmodified gNB using IPv4/GTP. | before, the SRGW maps the IPv4/GTP-U traffic to SRv6.</t> | |||
The UPFs are SR-aware. As before, the SRGW maps the | <t> S1 and C1 are two service segment endpoints. S1 represents a | |||
IPv4/GTP-U traffic to SRv6.</t> | VNF in the network, and C1 represents a router configured for | |||
<t> S1 and C1 are two service segment endpoints. | traffic engineering.</t> | |||
S1 represents a VNF in the network, and C1 represents a router | ||||
configured for Traffic Engineering.</t> | <figure anchor="fig_interworking_ipv4"> | |||
<figure anchor="fig_interworking_ipv4"> | <name>Enhanced Mode with Unchanged gNB IPv4/GTP-U Behavior</name> | |||
<name>Enhanced mode with unchanged gNB IPv4/GTP-U behavior</name> | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+----+ | +----+ | |||
IPv4/GTP-U -| S1 |- ___ | IPv4/GTP-U -| S1 |- ___ | |||
+--+ +-----+ [N3] / +----+ \ / | +--+ +-----+ [N3] / +----+ \ / | |||
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / | |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / | |||
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN | +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN | |||
GTP-U \ +------+ / +----+ +------+ \___ | GTP-U \ +------+ / +----+ +------+ \___ | |||
-| UPF1 |- SRv6 SRv6 | -| UPF1 |- SRv6 SRv6 | |||
+------+ TE | +------+ TE | |||
SR Gateway | SR Gateway | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Packet flow - Uplink</name> | <name>Packet Flow - Uplink</name> | |||
<t>The uplink packet flow is as follows:</t> | <t>The uplink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 | gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 | |||
unchanged IPv4/GTP | unchanged IPv4/GTP | |||
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function | SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function | |||
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) | S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) | |||
C1_out : (SRGW, U2::1) (A,Z) -> PSP | C1_out : (SRGW, U2::1) (A,Z) -> PSP | |||
UPF2_out: (A,Z) -> End.DT4 or End.DT6 | UPF2_out: (A,Z) -> End.DT4 or End.DT6 | |||
]]></artwork> | ]]></artwork> | |||
<t> The UE sends a packet destined to Z toward the gNB on a | <t> The UE sends a packet destined to Z toward the gNB on a | |||
specific bearer for that session. The gNB, which is unmodified, | specific bearer for that session. The gNB, which is unmodified, | |||
encapsulates the packet into a new IPv4, UDP, and GTP-Uheaders. | encapsulates the packet into a new IPv4, UDP, and GTP-U headers. | |||
The IPv4 DA, B, and the GTP-UTEID are the ones received at the | The IPv4 DA, B, and the GTP-UTEID are the ones received at the N2 | |||
N2 interface.</t> | interface.</t> | |||
<t> When the packet arrives at the SRGW for UPF1, the SRGW has an | <t> When the packet arrives at the SRGW for UPF1, the SRGW has a | |||
classification engine rule for incoming traffic from the | classification engine rule for incoming traffic from the gNB that | |||
gNB, that steers the traffic into an SR policy by using the | steers the traffic into an SR Policy by using the function | |||
function H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP | H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and | |||
headers and pushes an IPv6 header with its own SRH containing | pushes an IPv6 header with its own SRH containing the SIDs related | |||
the SIDs related to the SR policy associated with this traffic. | to the SR Policy associated with this traffic. The SRGW forwards | |||
The SRGW forwards according to the new IPv6 DA.</t> | according to the new IPv6 DA.</t> | |||
<t> S1 and C1 perform their related Endpoint | <t> S1 and C1 perform their related Endpoint functionality and | |||
functionality and forward the packet.</t> | forward the packet.</t> | |||
<t> When the packet arrives at UPF2, the active segment is (U2::1) | <t> When the packet arrives at UPF2, the active segment is (U2::1), | |||
which is bound to End.DT4/6 which performs the decapsulation | which is bound to End.DT4/6, which performs the decapsulation | |||
(removing the outer IPv6 header with all its extension headers) | (removing the outer IPv6 header with all its extension headers) | |||
and forwards toward the data network.</t> | and forwards toward the DN.</t> | |||
<t>Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U diffe | <t>Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U | |||
rs. This is due to the fact that IPv6/GTP-U can leverage the remote steering cap | differ. This is due to the fact that IPv6/GTP-U can leverage the remote | |||
abilities provided by the Segment Routing BSID. In IPv4 this construct is not av | steering capabilities provided by the Segment Routing BSID. In IPv4, this | |||
ailable, and building a similar mechanism would require a significant address co | construct is not available, and building a similar mechanism would require | |||
nsumption.</t> | a significant address consumption.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Uplink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Packet flow - Downlink</name> | <name>Packet Flow - Downlink</name> | |||
<t>The downlink packet flow is as follows:</t> | <t>The downlink packet flow is as follows:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
UPF2_in : (Z,A) -> UPF2 maps flow with SID | UPF2_in : (Z,A) -> UPF2 maps flow with SID | |||
<C1, S1,GW::SA:DA:TEID> | <C1, S1,GW::SA:DA:TEID> | |||
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red | UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red | |||
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) | C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) | |||
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) | S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) | |||
SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E | SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E | |||
gNB_out : (Z,A) | gNB_out : (Z,A) | |||
]]></artwork> | ]]></artwork> | |||
<t>When a packet destined to A arrives at the UPF2, the UPF2 | <t>When a packet destined to A arrives at the UPF2, the UPF2 | |||
performs a lookup in the table associated to A and finds the | performs a lookup in the table associated to A and finds the SID | |||
SID list <C1, S1, SRGW::SA:DA:TEID>. The UPF2 performs | list <C1, S1, SRGW::SA:DA:TEID>. The UPF2 performs an | |||
a H.Encaps.Red operation, encapsulating the packet into | H.Encaps.Red operation, encapsulating the packet into a new IPv6 | |||
a new IPv6 header with its corresponding SRH.</t> | header with its corresponding SRH.</t> | |||
<t>The nodes C1 and S1 perform their related Endpoint | <t>The nodes C1 and S1 perform their related Endpoint | |||
processing.</t> | processing.</t> | |||
<t>Once the packet arrives at the SRGW, the SRGW identifies the | <t>Once the packet arrives at the SRGW, the SRGW identifies the | |||
active SID as an End.M.GTP4.E function. The SRGW removes | active SID as an End.M.GTP4.E function. The SRGW removes the IPv6 | |||
the IPv6 header and all its extensions headers. The SRGW | header and all its extensions headers. The SRGW generates IPv4, | |||
generates an IPv4, UDP, and GTP-U headers. The IPv4 SA and | UDP, and GTP-U headers. The IPv4 SA and DA are received as SID | |||
DA are received as SID arguments. | arguments. The TEID in the generated GTP-U header is the | |||
The TEID in the generated GTP-U header is also the arguments | argument of the received End.M.GTP4.E SID. The SRGW pushes the | |||
of the received End.M.GTP4.E SID. The SRGW pushes the headers | headers to the packet and forwards the packet toward the gNB.</t> | |||
to the packet and forwards the packet toward the gNB.</t> | ||||
<t> When the packet arrives at the gNB, the packet is a regular | <t> When the packet arrives at the gNB, the packet is a regular | |||
IPv4/GTP-U packet. The gNB looks for the specific radio bearer | IPv4/GTP-U packet. The gNB looks for the specific radio bearer for | |||
for that TEID and forwards it on the bearer. This gNB behavior | that TEID and forwards it on the bearer. This gNB behavior is not | |||
is not modified from current and previous generations.</t> | modified from current and previous generations.</t> | |||
</section> | </section> | |||
<!-- End section "Packet flow - Downlink" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Scalability</name> | <name>Scalability</name> | |||
<t>For the downlink traffic, the SRGW is stateless. All the | <t>For downlink traffic, the SRGW is stateless. All the state | |||
state is in the SRH pushed by the UPF2. The UPF must have | is in the SRH pushed by the UPF2. The UPF must have this UE-base | |||
this UE-base state anyway (since it is its anchor point).</t> | state anyway (since it is its anchor point).</t> | |||
<t>For the uplink traffic, the state at the SRGW is dedicated on a | <t>For uplink traffic, the state at the SRGW is dedicated on a | |||
per UE/session basis according to a classification engine. | per-UE/session basis according to a classification engine. There | |||
There is state for steering the different sessions in the form of | is state for steering the different sessions in the form of an SR | |||
an SR Policy. However, SR policies are shared | Policy. However, SR Policies are shared among several | |||
among several UE/sessions.</t> | UE/sessions.</t> | |||
</section> | </section> | |||
<!-- End section "Scalability" --> | ||||
</section> | </section> | |||
<!-- End section "Interworking with IPv4 GTP" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Extensions to the interworking mechanisms</name> | <name>Extensions to the Interworking Mechanisms</name> | |||
<t>This section presents two mechanisms for interworking | <t>This section presents two mechanisms for interworking with gNBs | |||
with gNBs and UPFs that do not support SRv6. These mechanisms are u | and UPFs that do not support SRv6. These mechanisms are used to | |||
sed | support GTP-U over IPv4 and IPv6.</t> | |||
to support GTP-U over IPv4 and IPv6.</t> | ||||
<t>Even though these methods are presented as an extension to | <t> Even though these methods are presented as an extension to the | |||
the "Enhanced mode", it is straightforward in its | Enhanced mode, they are also applicable to the Traditional mode. | |||
applicability to the "Traditional mode".</t> | </t> | |||
</section> | </section> | |||
<!-- End section "Extensions .. interworking mechanisms" --> | ||||
</section> | </section> | |||
<!-- End "Enhanced mode with unchanged gNB GTP-U ..." --> | ||||
<section anchor="drop_in" numbered="true" toc="default"> | <section anchor="drop_in" numbered="true" toc="default"> | |||
<name>SRv6 Drop-in Interworking</name> | <name>SRv6 Drop-In Interworking</name> | |||
<t>This section introduces another mode useful for legacy gNB and UPFs t | <t>This section introduces another mode useful for legacy gNB and UPFs | |||
hat still operate with GTP-U. | that still operate with GTP-U. This mode provides an SRv6-enabled | |||
This mode provides an SRv6-enabled user plane in between | user plane in between two GTP-U tunnel endpoints.</t> | |||
two GTP-U tunnel endpoints.</t> | <t>This mode employs two SRGWs that map GTP-U traffic to SRv6 and | |||
<t>This mode employs two SRGWs that map GTP-U traffic to SRv6 and vice-v | vice versa.</t> | |||
ersa.</t> | <t>Unlike other interworking modes, in this mode, both of the mobility | |||
<t>Unlike other interworking modes, in this mode both of the mobility ov | overlay endpoints use GTP-U. Two SRGWs are deployed in either an N3 or | |||
erlay endpoints use GTP-U. | N9 interface to realize an intermediate SR Policy.</t> | |||
Two SRGWs are deployed in either N3 or N9 interface to realize an in | ||||
termediate SR policy.</t> | ||||
<figure anchor="fig_drop_in"> | ||||
<name>Example topology for SRv6 Drop-in mode</name> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<figure anchor="fig_drop_in"> | ||||
<name>Example Topology for SRv6 Drop-In Mode</name> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+----+ | +----+ | |||
-| S1 |- | -| S1 |- | |||
+-----+ / +----+ \ | +-----+ / +----+ \ | |||
| gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ | | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ | |||
+-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | | +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | | |||
GTP[N3]\ +--------+ / +----+ +--------+ +-----+ | GTP[N3]\ +--------+ / +----+ +--------+ +-----+ | |||
-| SRGW-A |- SRv6 SR Gateway-B GTP | -| SRGW-A |- SRv6 SR Gateway-B GTP | |||
+--------+ TE | +--------+ TE | |||
SR Gateway-A | SR Gateway-A | |||
]]></artwork> | ||||
</figure> | ||||
]]></artwork> | <t>The packet flow of <xref target="fig_drop_in" format="default"/> is | |||
</figure> | as follows:</t> | |||
<t>The packet flow of <xref target="fig_drop_in" format="default"/> is a | ||||
s | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
follows:</t> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) | gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) | |||
GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an | GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an | |||
End.M.GTP6.D.Di | End.M.GTP6.D.Di | |||
SID at SRGW-A | SID at SRGW-A | |||
S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) | S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) | |||
C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) | C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) | |||
GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an | GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an | |||
End.M.GTP6.E | End.M.GTP6.E | |||
SID at SRGW-B | SID at SRGW-B | |||
UPF_out : (A,Z) | UPF_out : (A,Z) | |||
]]></artwork> | ]]></artwork> | |||
<t>When a packet destined to Z is sent to the gNB, which is | ||||
unmodified (control-plane and user-plane remain GTP-U), | <t>When a packet destined to Z is sent to the gNB, which is unmodified | |||
gNB performs encapsulation into a new IP, UDP, and | (control plane and user plane remain GTP-U), gNB performs | |||
GTP-U headers. The IPv6 DA, U::1, and the GTP-U TEID are the ones | encapsulation into new IP, UDP, and GTP-U headers. The IPv6 DA, U::1, | |||
received at the N2 interface.</t> | and GTP-U TEID are the ones received at the N2 interface.</t> | |||
<t>The IPv6 address that was signaled over the N2 interface for that | <t>The IPv6 address that was signaled over the N2 interface for that | |||
PDU Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding | PDU Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding | |||
SID at SRGW-A. Hence the packet is routed to the SRGW.</t> | SID at SRGW-A. Hence, the packet is routed to the SRGW.</t> | |||
<t>When the packet arrives at SRGW-A, the SRGW identifies U::1 as an | <t>When the packet arrives at SRGW-A, the SRGW identifies U::1 as an | |||
End.M.GTP6.D.Di Binding SID (see <xref target="End-M-GTP6-D-Di" format | End.M.GTP6.D.Di Binding SID (see <xref target="End-M-GTP6-D-Di" | |||
="default"/>). | format="default"/>). Hence, the SRGW removes the IPv6, UDP, and GTP-U | |||
Hence, the SRGW removes the IPv6, UDP, and GTP-U headers, and pushes a | headers and pushes an IPv6 header with its own SRH containing the | |||
n | SIDs bound to the SR Policy associated with this Binding SID. There is | |||
IPv6 header with its own SRH containing the SIDs bound to the SR | one instance of the End.M.GTP6.D.Di SID per PDU type.</t> | |||
policy associated with this Binding SID. There is one instance of the | ||||
End.M.GTP6.D.Di SID per PDU type.</t> | ||||
<t>S1 and C1 perform their related Endpoint functionality and forward | <t>S1 and C1 perform their related Endpoint functionality and forward | |||
the packet.</t> | the packet.</t> | |||
<t>Once the packet arrives at SRGW-B, the SRGW identifies the active | <t>Once the packet arrives at SRGW-B, the SRGW identifies the active | |||
SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header and | SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header and | |||
all its extensions headers. The SRGW generates new IPv6, UDP, and GTP | all its extensions headers. The SRGW generates new IPv6, UDP, and GTP | |||
headers. The new IPv6 DA is U::1 which is the last SID in the | headers. The new IPv6 DA is U::1, which is the last SID in the | |||
received SRH. The TEID in the generated GTP-U header is an argument of | received SRH. The TEID in the generated GTP-U header is an argument of | |||
the received End.M.GTP6.E SID. The SRGW pushes the headers to the | the received End.M.GTP6.E SID. The SRGW pushes the headers to the | |||
packet and forwards the packet toward UPF. There is one instance of | packet and forwards the packet toward UPF. There is one instance of | |||
the End.M.GTP6.E SID per PDU type.</t> | the End.M.GTP6.E SID per PDU type.</t> | |||
<t>Once the packet arrives at UPF, the packet is a regular IPv6/GTP | <t>Once the packet arrives at UPF, the packet is a regular IPv6/GTP | |||
packet. The UPF looks for the specific rule for that TEID to forward | packet. The UPF looks for the specific rule for that TEID to forward | |||
the packet. This UPF behavior is not modified from current and | the packet. This UPF behavior is not modified from current and | |||
previous generations.</t> | previous generations.</t> | |||
</section> | </section> | |||
<!-- End section "SRv6 Drop-in Interworking" --> | ||||
</section> | </section> | |||
<!-- End section "User-plane behaviors" --> | ||||
<section anchor="srv6_functions" numbered="true" toc="default"> | <section anchor="srv6_functions" numbered="true" toc="default"> | |||
<name>SRv6 Segment Endpoint Mobility Behaviors</name> | <name>SRv6 Segment Endpoint Mobility Behaviors</name> | |||
<!-- Add text on functions used on UPF1, UPF2,... --> | ||||
<t>This section introduces new SRv6 Segment Endpoint Behaviors for the mob | <t>This section introduces new SRv6 Endpoint Behaviors for the | |||
ile user-plane. The behaviors described in this document are compatible with the | mobile user plane. The behaviors described in this document are | |||
NEXT and REPLACE flavors defined in <xref target="I-D.ietf-spring-srv6-srh-comp | compatible with the NEXT and REPLACE flavors defined in <xref | |||
ression" format="default" />.</t> | target="I-D.ietf-spring-srv6-srh-compression" format="default" />.</t> | |||
<section anchor="arguments-for-mobility" numbered="true" toc="default"> | <section anchor="arguments-for-mobility" numbered="true" toc="default"> | |||
<name>Args.Mob.Session</name> | <name>Args.Mob.Session</name> | |||
<t>Args.Mob.Session provide per-session information for charging, buffer | <t>Args.Mob.Session provides per-session information for charging, | |||
ing or other purposes required by some mobile nodes. | buffering, or other purposes required by some mobile nodes. The | |||
The Args.Mob.Session argument format is used in combination with End.M | Args.Mob.Session argument format is used in combination with the End.Map | |||
ap, | , | |||
End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 behaviors. Note t | End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2 behaviors. Note | |||
hat proposed format is applicable for | that proposed format is applicable for 5G networks, while similar | |||
5G networks, while similar formats could be used for legacy networks. | formats could be used for legacy networks. | |||
</t> | </t> | |||
<figure> | ||||
<name>Args.Mob.Session format</name> | <figure> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <name>Args.Mob.Session Format</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| QFI |R|U| PDU Session ID | | | QFI |R|U| PDU Session ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|PDU Sess(cont')| | |PDU Sess(cont')| | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<ul spacing="compact"> | ||||
<li> QFI: QoS Flow Identifier <xref target="TS.38415" format="default" | <dl spacing="normal" newline="false"> | |||
/></li> | <dt>QFI:</dt> | |||
<li> R: Reflective QoS Indication <xref target="TS.23501" format="def | <dd>QoS Flow Identifier <xref target="TS.38415" | |||
ault"/>. | format="default"/>.</dd> | |||
This parameter indicates the activation of reflective QoS towards the | <dt>R:</dt> | |||
UE for the transferred packet. Reflective QoS enables the UE to map UL User Plan | ||||
e traffic to QoS Flows without SMF provided QoS rules.</li> | <dd>Reflective QoS Indication <xref target="TS.23501" | |||
<li>U: Unused and for future use. MUST be 0 on transmission and | format="default"/>. This parameter indicates the activation of | |||
ignored on receipt.</li> | reflective QoS towards the UE for the transferred packet. Reflective | |||
<li>PDU Session ID: Identifier of PDU Session. The GTP-U equivalent is | QoS enables the UE to map uplink user-plane traffic to QoS flows withou | |||
TEID.</li> | t | |||
</ul> | SMF-provided QoS rules.</dd> | |||
<t>Args.Mob.Session is required in case that one SID aggregates | <dt>U:</dt> | |||
multiple PDU Sessions. Since the SRv6 SID is likely NOT to be | <dd>Unused and for future use. <bcp14>MUST</bcp14> be 0 on | |||
instantiated per PDU session, Args.Mob.Session helps the UPF to | transmission and ignored on receipt.</dd> | |||
perform the behaviors which require per QFI and/or per PDU Session | <dt>PDU Session ID:</dt> | |||
granularity.</t> | <dd>Identifier of PDU Session. The GTP-U equivalent is TEID.</dd> | |||
<t>Note that the encoding of user-plane messages (e.g., Echo Request, Ec | </dl> | |||
ho Reply, Error Indication and End Marker) is out of the scope of this draft. <x | <t>Args.Mob.Session is required in case one SID aggregates | |||
ref target="I-D.murakami-dmm-user-plane-message-encoding" /> defines one possibl | multiple PDU Sessions. Since the SRv6 SID is likely NOT to be | |||
e encoding.</t> | instantiated per PDU Session, Args.Mob.Session helps the UPF to | |||
perform the behaviors that require granularity per QFI and/or per PDU Se | ||||
ssion.</t> | ||||
<t>Note that the encoding of user-plane messages (e.g., Echo Request, | ||||
Echo Reply, Error Indication, and End Marker) is out of the scope of | ||||
this document. <xref | ||||
target="I-D.murakami-dmm-user-plane-message-encoding" /> defines one | ||||
possible encoding method.</t> | ||||
</section> | </section> | |||
<section anchor="end-map-function" numbered="true" toc="default"> | <section anchor="end-map-function" numbered="true" toc="default"> | |||
<name>End.MAP</name> | <name>End.MAP</name> | |||
<t>The "Endpoint behavior with SID mapping" behavior (End.MAP for | <t>End.MAP (Endpoint Behavior with SID mapping) | |||
short) is used in several scenarios. Particularly in mobility, | is used in several scenarios. Particularly in mobility, | |||
End.MAP is used by the intermediate UPFs.</t> | End.MAP is used by the intermediate UPFs.</t> | |||
<t>When node N receives a packet whose IPv6 DA is D and D is a local End | <t>When node N receives a packet whose IPv6 DA is D and D is a local End | |||
.MAP SID, N does:</t> | .MAP SID, N does the following:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. If (IPv6 Hop Limit <= 1) { | S01. If (IPv6 Hop Limit <= 1) { | |||
S02. Send an ICMP Time Exceeded message to the Source Address, | S02. Send an ICMP Time Exceeded message to the Source Address with | |||
Code 0 (Hop limit exceeded in transit), | Code 0 (Hop limit exceeded in transit), | |||
interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
S03. } | S03. } | |||
S04. Decrement IPv6 Hop Limit by 1 | S04. Decrement IPv6 Hop Limit by 1 | |||
S05. Update the IPv6 DA with the new mapped SID | S05. Update the IPv6 DA with the new mapped SID | |||
S06. Submit the packet to the egress IPv6 FIB lookup for | S06. Submit the packet to the egress IPv6 FIB lookup for | |||
transmission to the new destination | transmission to the new destination | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Notes: | ||||
The SRH is not modified (neither the SID, nor the SL value).</t> | <t>Note: The SRH is not modified (neither the SID nor the SL | |||
value).</t> | ||||
</section> | </section> | |||
<section anchor="End-M-GTP6-D" numbered="true" toc="default"> | <section anchor="End-M-GTP6-D" numbered="true" toc="default"> | |||
<name>End.M.GTP6.D</name> | <name>End.M.GTP6.D</name> | |||
<t>The "Endpoint behavior with IPv6/GTP-U decapsulation into SR policy" | <t>End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR | |||
behavior (End.M.GTP6.D for short) is used in interworking scenario | Policy) is used in the interworking | |||
for the uplink towards SRGW from the legacy gNB using IPv6/GTP. | scenario for the uplink towards SRGW from the legacy gNB using | |||
Any SID instance of this behavior is associated with an SR Policy B | IPv6/GTP. Any SID instance of this behavior is associated with an SR | |||
and an IPv6 Source Address S. | Policy B and an IPv6 Source Address S. | |||
</t> | </t> | |||
<t>When the SR Gateway node N receives a packet destined to D and | <t>When the SR Gateway node N receives a packet destined to D, and D | |||
D is a local End.M.GTP6.D SID, N does:</t> | is a local End.M.GTP6.D SID, N does the following:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. When an SRH is processed { | S01. When an SRH is processed { | |||
S02. If (Segments Left != 0) { | S02. If (Segments Left != 0) { | |||
S03. Send an ICMP Parameter Problem to the Source Address, | S03. Send an ICMP Parameter Problem to the Source Address with | |||
Code 0 (Erroneous header field encountered), | Code 0 (Erroneous header field encountered) and | |||
Pointer set to the Segments Left field, | Pointer set to the Segments Left field, | |||
interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
S04. } | S04. } | |||
S05. Proceed to process the next header in the packet | S05. Proceed to process the next header in the packet | |||
S06. } | S06. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>When processing the Upper-layer header of a packet matching a FIB ent | ||||
ry locally instantiated as an End.M.GTP6.D SID, N does:</t> | <t>When processing the Upper-Layer header of a packet matching a FIB ent | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ry locally instantiated as an End.M.GTP6.D SID, N does the following:</t> | |||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) { | S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) { | |||
S02. Copy the GTP-U TEID and QFI to buffer memory | S02. Copy the GTP-U TEID and QFI to buffer memory | |||
S03. Pop the IPv6, UDP, and GTP-U Headers | S03. Pop the IPv6, UDP, and GTP-U headers | |||
S04. Push a new IPv6 header with its own SRH containing B | S04. Push a new IPv6 header with its own SRH containing B | |||
S05. Set the outer IPv6 SA to S | S05. Set the outer IPv6 SA to S | |||
S06. Set the outer IPv6 DA to the first SID of B | S06. Set the outer IPv6 DA to the first SID of B | |||
S07. Set the outer Payload Length, Traffic Class, Flow Label, | S07. Set the outer Payload Length, Traffic Class, Flow Label, | |||
Hop Limit, and Next-Header (NH) fields | Hop Limit, and Next Header (NH) fields | |||
S08. Write in the SRH[0] the Args.Mob.Session based on | S08. Write in the SRH[0] the Args.Mob.Session based on | |||
the information of buffer memory | the information in buffer memory | |||
S09. Submit the packet to the egress IPv6 FIB lookup and | S09. Submit the packet to the egress IPv6 FIB lookup for | |||
transmission to the new destination | transmission to the new destination | |||
S10. } Else { | S10. } Else { | |||
S11. Process as per [RFC8986] Section 4.1.1 | S11. Process as per [RFC8986], Section 4.1.1 | |||
S12. } | S12. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Notes: | ||||
S07. The NH is set based on the SID parameter. There is one | <t>Notes:</t> | |||
instantiation of the End.M.GTP6.D SID per PDU Session Type, | <ul spacing="normal"> | |||
hence the NH is already known in advance. For the IPv4v6 PDU | <li>In line S07, the NH is set based on the SID parameter. There is one | |||
Session Type, in addition the router inspects the first nibble of the | instantiation of the End.M.GTP6.D SID per PDU Session Type; | |||
PDU to know the NH value.</t> | hence, the NH is already known in advance. In addition, for the IPv4v6 | |||
<t>The last segment SHOULD be | PDU | |||
followed by an Args.Mob.Session argument space which is used to | Session Type, the router inspects the first nibble of the | |||
provide the session identifiers, as shown in line S08.</t> | PDU to know the NH value.</li> | |||
<li>The last segment <bcp14>SHOULD</bcp14> be | ||||
followed by an Args.Mob.Session argument space, which is used to | ||||
provide the session identifiers, as shown in line S08.</li> | ||||
</ul> | ||||
</section> | </section> | |||
<!-- End section "End.M.GTP6.D" --> | ||||
<section anchor="End-M-GTP6-D-Di" numbered="true" toc="default"> | <section anchor="End-M-GTP6-D-Di" numbered="true" toc="default"> | |||
<name>End.M.GTP6.D.Di</name> | <name>End.M.GTP6.D.Di</name> | |||
<t>The "Endpoint behavior with IPv6/GTP-U decapsulation into SR policy f | <t>End.M.GTP6.D.Di (Endpoint Behavior with IPv6/GTP-U decapsulation into | |||
or | SR Policy | |||
Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 | for Drop-in Mode) is used in the SRv6 | |||
drop-in interworking scenario described in <xref target="drop_in" format | drop-in interworking scenario described in <xref target="drop_in" | |||
="default"/>. The | format="default"/>. The difference between End.M.GTP6.D as another | |||
difference between End.M.GTP6.D as another variant of IPv6/GTP | variant of the IPv6/GTP decapsulation function is that the original IPv6 | |||
decapsulation function is that the original IPv6 DA of the GTP-U packet | DA of the GTP-U packet is preserved as the last SID in SRH.</t> | |||
is | <t>Any SID instance of this behavior is associated with an SR Policy B | |||
preserved as the last SID in SRH.</t> | and an IPv6 Source Address S.</t> | |||
<t>Any SID instance of this behavior is associated with an SR Policy B a | <t>When the SR Gateway node N receives a packet destined to D, and | |||
nd an IPv6 Source Address S.</t> | D is a local End.M.GTP6.D.Di SID, N does the following:</t> | |||
<t>When the SR Gateway node N receives a packet destined to D and | ||||
D is a local End.M.GTP6.D.Di SID, N does:</t> | <sourcecode type="pseudocode"><![CDATA[ | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
S01. When an SRH is processed { | S01. When an SRH is processed { | |||
S02. If (Segments Left != 0) { | S02. If (Segments Left != 0) { | |||
S03. Send an ICMP Parameter Problem to the Source Address, | S03. Send an ICMP Parameter Problem to the Source Address with | |||
Code 0 (Erroneous header field encountered), | Code 0 (Erroneous header field encountered) and | |||
Pointer set to the Segments Left field, | Pointer set to the Segments Left field, | |||
interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
S04. } | S04. } | |||
S05. Proceed to process the next header in the packet | S05. Proceed to process the next header in the packet | |||
S06. } | S06. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>When processing the Upper-layer header of a packet matching a FIB ent | ||||
ry locally instantiated as an End.M.GTP6.Di SID, N does:</t> | <t>When processing the Upper-Layer header of a packet matching a FIB | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | entry locally instantiated as an End.M.GTP6.Di SID, N does the | |||
following:</t> | ||||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { | S01. If (Next Header = UDP & UDP_Dest_port = GTP) { | |||
S02. Copy D to buffer memory | S02. Copy D to buffer memory | |||
S03. Pop the IPv6, UDP, and GTP-U Headers | S03. Pop the IPv6, UDP, and GTP-U headers | |||
S04. Push a new IPv6 header with its own SRH containing B | S04. Push a new IPv6 header with its own SRH containing B | |||
S05. Set the outer IPv6 SA to S | S05. Set the outer IPv6 SA to S | |||
S06. Set the outer IPv6 DA to the first SID of B | S06. Set the outer IPv6 DA to the first SID of B | |||
S07. Set the outer Payload Length, Traffic Class, Flow Label, | S07. Set the outer Payload Length, Traffic Class, Flow Label, | |||
Hop Limit, and Next-Header fields | Hop Limit, and Next Header fields | |||
S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly | S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly | |||
S09. Submit the packet to the egress IPv6 FIB lookup and | S09. Submit the packet to the egress IPv6 FIB lookup for | |||
transmission to the new destination | transmission to the new destination | |||
S10. } Else { | S10. } Else { | |||
S11. Process as per [RFC8986] Section 4.1.1 | S11. Process as per [RFC8986], Section 4.1.1 | |||
S12. } | S12. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Notes: | ||||
S07. The NH is set based on the SID parameter. There is one | <t>Notes:</t> | |||
instantiation of the End.M.GTP6.Di SID per PDU Session Type, | <ul spacing="normal"> | |||
hence the NH is already known in advance. For the IPv4v6 PDU | <li>In line S07, the NH is set based on the SID parameter. There is one | |||
Session Type, in addition the router inspects the first nibble of the | instantiation of the End.M.GTP6.Di SID per PDU Session Type; hence, | |||
PDU to know the NH value.</t> | the NH is already known in advance. In addition, for the IPv4v6 PDU Sess | |||
<t>S SHOULD be an End.M.GTP6.E SID instantiated | ion Type, | |||
at the SR gateway.</t> | the router inspects the first nibble of the PDU to know | |||
the NH value.</li> | ||||
<li>S <bcp14>SHOULD</bcp14> be an End.M.GTP6.E SID instantiated | ||||
at the SR Gateway.</li> | ||||
</ul> | ||||
</section> | </section> | |||
<!-- End section "End.M.GTP6.D.Di" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>End.M.GTP6.E</name> | <name>End.M.GTP6.E</name> | |||
<t>The "Endpoint behavior with encapsulation for IPv6/GTP-U tunnel" | <t>End.M.GTP6.E (Endpoint Behavior with encapsulation for IPv6/GTP-U tun | |||
behavior (End.M.GTP6.E for short) is used among others in the interworki | nel" | |||
ng scenario | behavior) is used among others in the | |||
for the downlink toward the legacy gNB using IPv6/GTP.</t> | interworking scenario for the downlink toward the legacy gNB using | |||
<t>The prefix of End.M.GTP6.E SID MUST be followed by the | IPv6/GTP.</t> | |||
Args.Mob.Session argument space which is used to provide the session | <t>The prefix of End.M.GTP6.E SID <bcp14>MUST</bcp14> be followed by | |||
identifiers.</t> | the Args.Mob.Session argument space, which is used to provide the | |||
session identifiers.</t> | ||||
<t>When the SR Gateway node N receives a packet destined to D, and | <t>When the SR Gateway node N receives a packet destined to D, and | |||
D is a local End.M.GTP6.E SID, N does the following:</t> | D is a local End.M.GTP6.E SID, N does the following:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. When an SRH is processed { | S01. When an SRH is processed { | |||
S02. If (Segments Left != 1) { | S02. If (Segments Left != 1) { | |||
S03. Send an ICMP Parameter Problem to the Source Address, | S03. Send an ICMP Parameter Problem to the Source Address with | |||
Code 0 (Erroneous header field encountered), | Code 0 (Erroneous header field encountered) and | |||
Pointer set to the Segments Left field, | Pointer set to the Segments Left field, | |||
interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
S04. } | S04. } | |||
S05. Proceed to process the next header in the packet | S05. Proceed to process the next header in the packet | |||
S06. } | S06. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>When processing the Upper-layer header of a packet matching a FIB ent | ||||
ry locally instantiated as an End.M.GTP6.E SID, N does:</t> | <t>When processing the Upper-Layer header of a packet matching a FIB ent | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ry locally instantiated as an End.M.GTP6.E SID, N does the following:</t> | |||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. Copy SRH[0] and D to buffer memory | S01. Copy SRH[0] and D to buffer memory | |||
S02. Pop the IPv6 header and all its extension headers | S02. Pop the IPv6 header and all its extension headers | |||
S03. Push a new IPv6 header with a UDP/GTP-U Header | S03. Push a new IPv6 header with a UDP/GTP-U header | |||
S04. Set the outer IPv6 SA to S | S04. Set the outer IPv6 SA to S | |||
S05. Set the outer IPv6 DA from buffer memory | S05. Set the outer IPv6 DA from buffer memory | |||
S06. Set the outer Payload Length, Traffic Class, Flow Label, | S06. Set the outer Payload Length, Traffic Class, Flow Label, | |||
Hop Limit, and Next-Header fields | Hop Limit, and Next Header fields | |||
S07. Set the GTP-U TEID (from buffer memory) | S07. Set the GTP-U TEID (from buffer memory) | |||
S08. Submit the packet to the egress IPv6 FIB lookup and | S08. Submit the packet to the egress IPv6 FIB lookup for | |||
transmission to the new destination | transmission to the new destination | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Notes: | ||||
An End.M.GTP6.E SID MUST always be the penultimate SID. | <t>Notes:</t> | |||
<ul spacing="normal"> | ||||
<li>An End.M.GTP6.E SID <bcp14>MUST</bcp14> always be the penultimate SI | ||||
D. | ||||
The TEID is extracted from the argument space of the current | The TEID is extracted from the argument space of the current | |||
SID.</t> | SID.</li> | |||
<t> The source address S SHOULD be an End.M.GTP6.D SID instantiated at t | <li> The source address S <bcp14>SHOULD</bcp14> be an End.M.GTP6.D SID i | |||
he egress SR gateway.</t> | nstantiated at the egress SR Gateway.</li> | |||
</ul> | ||||
</section> | </section> | |||
<!-- End section "End.M.GTP6.E" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>End.M.GTP4.E</name> | <name>End.M.GTP4.E</name> | |||
<t>The "Endpoint behavior with encapsulation for IPv4/GTP-U tunnel" | <t>End.M.GTP4.E (Endpoint Behavior with encapsulation for IPv4/GTP-U | |||
behavior (End.M.GTP4.E for short) is used in the downlink when | tunnel) is used in the downlink when doing interworking with legacy | |||
doing interworking with legacy gNB using IPv4/GTP.</t> | gNB using IPv4/GTP.</t> | |||
<t>When the SR Gateway node N receives a packet destined to S and S | <t>When the SR Gateway node N receives a packet destined to S, and S | |||
is a local End.M.GTP4.E SID, N does:</t> | is a local End.M.GTP4.E SID, N does the following:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. When an SRH is processed { | S01. When an SRH is processed { | |||
S02. If (Segments Left != 0) { | S02. If (Segments Left != 0) { | |||
S03. Send an ICMP Parameter Problem to the Source Address, | S03. Send an ICMP Parameter Problem to the Source Address with | |||
Code 0 (Erroneous header field encountered), | Code 0 (Erroneous header field encountered) and | |||
Pointer set to the Segments Left field, | Pointer set to the Segments Left field, | |||
interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
S04. } | S04. } | |||
S05. Proceed to process the next header in the packet | S05. Proceed to process the next header in the packet | |||
S06. } | S06. } | |||
]]></artwork> | ]]></sourcecode> | |||
<t>When processing the Upper-layer header of a packet matching a FIB ent | ||||
ry locally instantiated as an End.M.GTP4.E SID, N does:</t> | <t>When processing the Upper-Layer header of a packet matching a FIB ent | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ry locally instantiated as an End.M.GTP4.E SID, N does the following:</t> | |||
<sourcecode type="pseudocode"><![CDATA[ | ||||
S01. Store the IPv6 DA and SA in buffer memory | S01. Store the IPv6 DA and SA in buffer memory | |||
S02. Pop the IPv6 header and all its extension headers | S02. Pop the IPv6 header and all its extension headers | |||
S03. Push a new IPv4 header with a UDP/GTP-U Header | S03. Push a new IPv4 header with a UDP/GTP-U header | |||
S04. Set the outer IPv4 SA and DA (from buffer memory) | S04. Set the outer IPv4 SA and DA (from buffer memory) | |||
S05. Set the outer Total Length, DSCP, Time To Live, and | S05. Set the outer Total Length, DSCP, Time To Live, and | |||
Next-Header fields | Next Header fields | |||
S06. Set the GTP-U TEID (from buffer memory) | S06. Set the GTP-U TEID (from buffer memory) | |||
S07. Submit the packet to the egress IPv4 FIB lookup and | S07. Submit the packet to the egress IPv4 FIB lookup for | |||
transmission to the new destination | transmission to the new destination | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Notes: | ||||
The End.M.GTP4.E SID in S has the following format:</t> | <t>Notes:</t> | |||
<figure> | <ul spacing="normal"> | |||
<name>End.M.GTP4.E SID Encoding</name> | <li><t>The End.M.GTP4.E SID in S has the following format:</t> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
<figure> | ||||
<name>End.M.GTP4.E SID Encoding</name> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
0 127 | 0 127 | |||
+-----------------------+-------+----------------+---------+ | +-----------------------+-------+----------------+---------+ | |||
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | | | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | | |||
+-----------------------+-------+----------------+---------+ | +-----------------------+-------+----------------+---------+ | |||
128-a-b-c a b c | 128-a-b-c a b c | |||
]]></artwork> | ||||
</figure> | ||||
</li> | ||||
]]></artwork> | <li><t>The IPv6 Source Address has the following format:</t> | |||
</figure> | ||||
<t>The IPv6 Source Address has the following format:</t> | <figure> | |||
<figure> | <name>IPv6 SA Encoding for End.M.GTP4.E</name> | |||
<name>IPv6 SA Encoding for End.M.GTP4.E</name> | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
0 127 | 0 127 | |||
+----------------------+--------+--------------------------+ | +----------------------+--------+--------------------------+ | |||
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | | | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | | |||
+----------------------+--------+--------------------------+ | +----------------------+--------+--------------------------+ | |||
128-a-b a b | 128-a-b a b | |||
]]></artwork> | ||||
]]></artwork> | </figure> | |||
</figure> | </li> | |||
</ul> | ||||
</section> | </section> | |||
<!-- End section "End.M.GTP4.E" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>H.M.GTP4.D</name> | <name>H.M.GTP4.D</name> | |||
<t>The "SR Policy Headend with tunnel decapsulation and map to an SRv6 | <t>H.M.GTP4.D (SR Policy Headend with tunnel decapsulation and map to an | |||
policy" behavior (H.M.GTP4.D for short) is used in the direction | SRv6 | |||
from legacy IPv4 user-plane to SRv6 user-plane network.</t> | policy) is used in the direction | |||
from the legacy IPv4 user plane to the SRv6 user-plane network.</t> | ||||
<t>When the SR Gateway node N receives a packet destined to a | <t>When the SR Gateway node N receives a packet destined to a | |||
SRGW-IPv4-Prefix, N does:</t> | SRGW-IPv4-Prefix, N does the following:</t> | |||
<artwork align="left" name="" type="" alt=""><![CDATA[ | ||||
<artwork align="left" name="" type="" alt=""><![CDATA[ | ||||
S01. IF Payload == UDP/GTP-U THEN | S01. IF Payload == UDP/GTP-U THEN | |||
S02. Pop the outer IPv4 header and UDP/GTP-U headers | S02. Pop the outer IPv4 header and UDP/GTP-U headers | |||
S03. Copy IPv4 DA, TEID to form SID B | S03. Copy IPv4 DA and TEID to form SID B | |||
S04. Copy IPv4 SA to form IPv6 SA B' | S04. Copy IPv4 SA to form IPv6 SA B' | |||
S05. Encapsulate the packet into a new IPv6 header | S05. Encapsulate the packet into a new IPv6 header | |||
S06. Set the IPv6 DA = B | S06. Set the IPv6 DA = B | |||
S07. Forward along the shortest path to B | S07. Forward along the shortest path to B | |||
S08. ELSE | S08. ELSE | |||
S09. Drop the packet | S09. Drop the packet | |||
]]></artwork> | ]]></artwork> | |||
<t>The SID B has the following format:</t> | <t>The SID B has the following format:</t> | |||
<figure> | ||||
<name>H.M.GTP4.D SID Encoding</name> | <figure> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | <name>H.M.GTP4.D SID Encoding</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
0 127 | 0 127 | |||
+-----------------------+-------+----------------+---------+ | +-----------------------+-------+----------------+---------+ | |||
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | | |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | | |||
+-----------------------+-------+----------------+---------+ | +-----------------------+-------+----------------+---------+ | |||
128-a-b-c a b c | 128-a-b-c a b c | |||
]]></artwork> | ||||
</figure> | ||||
]]></artwork> | <t> The SID B <bcp14>MAY</bcp14> be an SRv6 Binding SID instantiated at | |||
</figure> | the first | |||
<t> The SID B MAY be an SRv6 Binding SID instantiated at the first | UPF (U1) to bind an SR Policy <xref target="RFC9256" format="default"/>. | |||
UPF (U1) to bind an SR policy <xref target="RFC9256" format="default"/>. | </t> | |||
</t> | ||||
</section> | </section> | |||
<!-- End section "T.M.Tmap" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>End.Limit: Rate Limiting behavior</name> | <name>End.Limit</name> | |||
<t> The mobile user-plane requires a rate-limit feature. For this | <t> The mobile user plane requires a rate-limit feature. For this | |||
purpose, this document defines a new behavior "End.Limit". | purpose, this document defines a new behavior, called "End.Limit". | |||
The "End.Limit" behavior encodes in its arguments the | The "End.Limit" behavior encodes in its arguments the rate-limiting | |||
rate limiting parameter that should be applied to this packet. | parameter that should be applied to this packet. Multiple flows of | |||
Multiple flows of packets should have the same group identifier | packets should have the same group identifier in the SID when those | |||
in the SID when those flows are in the same AMBR (Aggregate Maximum B | flows are in the same AMBR (Aggregate Maximum Bit Rate) group. The | |||
it Rate) group. | encoding format of the rate-limit segment SID is as follows:</t> | |||
The encoding format of the rate limit | ||||
segment SID is as follows:</t> | <figure> | |||
<figure> | <name>End.Limit: Rate-Limiting Behavior Argument Format</name> | |||
<name>End.Limit: Rate limiting behavior argument format</name> | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+----------------------+----------+-----------+ | +----------------------+----------+-----------+ | |||
| LOC+FUNC rate-limit | group-id | limit-rate| | | LOC+FUNC rate-limit | group-id | limit-rate| | |||
+----------------------+----------+-----------+ | +----------------------+----------+-----------+ | |||
128-i-j i j | 128-i-j i j | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> If the limit-rate bits are set to zero, the node should | <t> If the limit-rate bits are set to zero, the node should | |||
not do rate limiting unless static configuration or | not do rate limiting unless static configuration or | |||
control-plane sets the limit rate associated to the SID.</t> | control plane sets the limit rate associated to the SID.</t> | |||
</section> | </section> | |||
<!-- End section "End.Limit: Rate Limiting function" --> | ||||
</section> | </section> | |||
<!-- End section "" --> | ||||
<section anchor="pdu_sessions" numbered="true" toc="default"> | <section anchor="pdu_sessions" numbered="true" toc="default"> | |||
<name>SRv6 supported 3GPP PDU session types</name> | <name>SRv6-Supported 3GPP PDU Session Types</name> | |||
<t>The 3GPP <xref target="TS.23501" format="default"/> defines the followi | <t>The 3GPP <xref target="TS.23501" format="default"/> defines the | |||
ng PDU session | following PDU Session Types: | |||
types: | ||||
</t> | </t> | |||
<ul spacing="compact"> | <ul spacing="normal"> | |||
<li>IPv4</li> | <li>IPv4</li> | |||
<li>IPv6</li> | <li>IPv6</li> | |||
<li>IPv4v6</li> | <li>IPv4v6</li> | |||
<li>Ethernet</li> | <li>Ethernet</li> | |||
<li>Unstructured</li> | <li>Unstructured</li> | |||
</ul> | </ul> | |||
<t> SRv6 supports the 3GPP PDU session types without any protocol | ||||
overhead by using the corresponding SRv6 behaviors (End.DX4, | <t> SRv6 supports the 3GPP PDU Session Types without any protocol | |||
End.DT4 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 | overhead by using the corresponding SRv6 behaviors:</t> | |||
PDU sessions; End.DT46 for IPv4v6 PDU sessions; End.DX2 | <ul spacing="normal"> | |||
for L2 and Unstructured PDU sessions).</t> | <li>End.DX4 and End.DT4 for IPv4 PDU Sessions</li> | |||
<li>End.DX6, End.DT6, and End.T for IPv6 PDU Sessions</li> | ||||
<li>End.DT46 for IPv4v6 PDU Sessions</li> | ||||
<li>End.DX2 for L2 and Unstructured PDU Sessions</li> | ||||
</ul> | ||||
</section> | </section> | |||
<!-- End section "SRv6 supported PDU session types" --> | ||||
<section anchor="netslice" numbered="true" toc="default"> | <section anchor="netslice" numbered="true" toc="default"> | |||
<name>Network Slicing Considerations</name> | <name>Network Slicing Considerations</name> | |||
<t>A mobile network may be required to implement "network slices", | <t>A mobile network may be required to implement "network slices", | |||
which logically separate network resources within the same SR Domain. | which logically separate network resources within the same SR domain. | |||
</t> | </t> | |||
<t><xref target="RFC9256" format="default"/> | ||||
<t><xref target="RFC9256" format="default"/> | ||||
describes a solution to build basic network slices with SR. | describes a solution to build basic network slices with SR. | |||
Depending on the requirements, these slices can be further | Depending on the requirements, these slices can be further | |||
refined by adopting the mechanisms from: | refined by adopting the mechanisms from: | |||
</t> | </t> | |||
<ul spacing="compact"> | <ul spacing="normal"> | |||
<li>IGP Flex-Algo | <li>IGP Flex-Algo | |||
<xref target="I-D.ietf-lsr-flex-algo" format="default"/></li> | <xref target="RFC9350" format="default"/></li> | |||
<li>Inter-Domain policies | <li>Inter-Domain policies | |||
<xref target="RFC9087" format="default"/></li> | <xref target="RFC9087" format="default"/></li> | |||
</ul> | </ul> | |||
<t>Furthermore, these can be combined with ODN/AS (On Demand Nexthop/Autom | ||||
ated Steering) | <t>Furthermore, these can be combined with ODN/AS (On-Demand Next Hop / Au | |||
tomated Steering) | ||||
<xref target="RFC9256" format="default"/> for | <xref target="RFC9256" format="default"/> for | |||
automated slice provisioning and traffic steering.</t> | automated slice provisioning and traffic steering.</t> | |||
<t>Further details on how these tools can be used to create | <t>Further details on how these tools can be used to create | |||
end to end network slices are documented in | end-to-end network slices are documented in | |||
<xref target="I-D.ali-spring-network-slicing-building-blocks" format=" | <xref target="I-D.ali-teas-spring-ns-building-blocks" format="default" | |||
default"/>.</t> | />.</t> | |||
</section> | </section> | |||
<!-- End section "Network Slicing Considerations" --> | ||||
<section anchor="c-plane" numbered="true" toc="default"> | <section anchor="c-plane" numbered="true" toc="default"> | |||
<name>Control Plane Considerations</name> | <name>Control Plane Considerations</name> | |||
<t>This document focuses on user-plane behavior and its | <t>This document focuses on user-plane behavior and its independence | |||
independence from the control plane. While the SRv6 mobile user-plane | from the control plane. While the SRv6 mobile user-plane behaviors may | |||
behaviors may be utilized in emerging architectures, such as <xref target="I-D. | be utilized in emerging architectures (for example, those described in | |||
gundavelli-dmm-mfa" format="default"/>, <xref target="I-D.mhkk-dmm-srv6mup-archi | <xref target="I-D.gundavelli-dmm-mfa" format="default"/> and <xref | |||
tecture" format="default"/> for example, require control plane support for the u | target="I-D.mhkk-dmm-srv6mup-architecture" format="default"/>), this | |||
ser-plane, this document does not impose any change to the existent mobility con | document does not impose any change to the existent mobility control | |||
trol plane.</t> | plane. | |||
</t> | ||||
<t> <xref target="IANA" format="default"/> allocates SRv6 | <t> <xref target="IANA" format="default"/> allocates SRv6 | |||
Segment Endpoint Behavior codepoints for the new behaviors defined in | Endpoint Behavior codepoints for the new behaviors defined in this | |||
this | document.</t> | |||
document.</t> | ||||
</section> | </section> | |||
<!-- End section "Control Plane Considerations" --> | ||||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t> The security considerations for Segment Routing are discussed in | <t> The security considerations for Segment Routing are discussed in | |||
<xref target="RFC8402" format="default"/>. More specifically for SRv | <xref target="RFC8402" format="default"/>. More specifically, for SRv6, | |||
6 the security considerations | the security considerations and the mechanisms for securing an SR domain | |||
and the mechanisms for securing an SR domain are discussed in | are discussed in <xref target="RFC8754" format="default"/>. Together, | |||
<xref target="RFC8754" format="default"/>. Together, they describe t | they describe the required security mechanisms that allow establishment | |||
he required security mechanisms | of an SR domain of trust to operate SRv6-based services for internal | |||
that allow establishment of an SR domain of trust to operate | traffic while preventing any external traffic from accessing or | |||
SRv6-based services for internal traffic while preventing any | exploiting the SRv6-based services.</t> | |||
external traffic from accessing or exploiting the SRv6-based | <t>The technology described in this document is applied to a mobile | |||
services.</t> | network that is within the SR domain. It's important to note the | |||
<t>The technology described in this document is applied to a mobile networ | resemblance between the SR domain and the 3GPP Packet Core Domain.</t> | |||
k that is within the SR Domain. It's important to note the ressemblance between | <t>This document introduces new SRv6 Endpoint Behaviors. Those behaviors | |||
the SR Domain and the 3GPP Packet Core Domain.</t> | operate on control plane information, including information within the | |||
<t>This document introduces new SRv6 Endpoint Behaviors. Those | received SRH payload on which the behaviors operate. Altering the | |||
behaviors operate on control plane information, including information | behaviors requires that an attacker alter the SR domain as defined in | |||
within the received SRH payload on which the behaviors operate. Altering | <xref target="RFC8754" format="default"/>. Those behaviors do not need | |||
the behaviors requires that an attacker alter the SR Domain as defined in <xre | any special security consideration given that they are deployed within tha | |||
f target="RFC8754" format="default"/>. | t | |||
Those behaviors do not need any special security consideration given that it is | SR domain.</t> | |||
deployed within that SR Domain.</t> | ||||
</section> | </section> | |||
<!-- End section "Security Considerations" --> | ||||
<section anchor="IANA" numbered="true" toc="default"> | <section anchor="IANA" numbered="true" toc="default"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t> The following values have been allocated within the "SRv6 Endpoint Beh | ||||
aviors" <xref target="RFC8986" format="default"/> | <t>The following values have been allocated in the "SRv6 Endpoint | |||
sub-registry belonging to the top-level | Behaviors" <xref target="RFC8986" format="default"/> subregistry | |||
"Segment Routing Parameters" registry:</t> | within the top-level "Segment Routing Parameters" registry:</t> | |||
<table anchor="endpoint_opcodes" align="center"> | <table anchor="endpoint_opcodes" align="center"> | |||
<name>SRv6 Mobile User-plane Endpoint Behavior Types</name> | <name>SRv6 Mobile User-Plane Endpoint Behavior Types</name> | |||
<thead> | <thead> | |||
<tr> | <tr> | |||
<th align="left">Value</th> | <th align="left">Value</th> | |||
<th align="center">Hex</th> | <th align="center">Hex</th> | |||
<th align="center">Endpoint behavior</th> | <th align="center">Endpoint Behavior</th> | |||
<th align="center">Reference</th> | <th align="center">Reference</th> | |||
<th align="center">Change Controller</th> | <th align="center">Change Controller</th> | |||
</tr> | </tr> | |||
</thead> | </thead> | |||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<td align="left">40</td> | <td align="left">40</td> | |||
<td align="center">0x0028</td> | <td align="center">0x0028</td> | |||
<td align="center">End.MAP</td> | <td align="center">End.MAP</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">41</td> | <td align="left">41</td> | |||
<td align="center">0x0029</td> | <td align="center">0x0029</td> | |||
<td align="center">End.Limit</td> | <td align="center">End.Limit</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">69</td> | <td align="left">69</td> | |||
<td align="center">0x0045</td> | <td align="center">0x0045</td> | |||
<td align="center">End.M.GTP6.D</td> | <td align="center">End.M.GTP6.D</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">70</td> | <td align="left">70</td> | |||
<td align="center">0x0046</td> | <td align="center">0x0046</td> | |||
<td align="center">End.M.GTP6.Di</td> | <td align="center">End.M.GTP6.Di</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">71</td> | <td align="left">71</td> | |||
<td align="center">0x0047</td> | <td align="center">0x0047</td> | |||
<td align="center">End.M.GTP6.E</td> | <td align="center">End.M.GTP6.E</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td align="left">72</td> | <td align="left">72</td> | |||
<td align="center">0x0048</td> | <td align="center">0x0048</td> | |||
<td align="center">End.M.GTP4.E</td> | <td align="center">End.M.GTP4.E</td> | |||
<td align="center">[This.ID]</td> | <td align="center">RFC 9433</td> | |||
<td align="center">IETF</td> | <td align="center">IETF</td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
</section> | </section> | |||
<!-- End section "IANA Considerations" --> | ||||
<section numbered="true" toc="default"> | ||||
<name>Contributors</name> | ||||
<t>Kentaro Ebisawa | ||||
Toyota Motor Corporation | ||||
Japan</t> | ||||
<t>Email: ebisawa@toyota-tokyo.tech</t> | ||||
<t>Tetsuya Murakami | ||||
Arrcus, Inc. | ||||
United States of America</t> | ||||
<t>Email: tetsuya.ietf@gmail.com</t> | ||||
<t>Charles E. Perkins | ||||
Lupin Lodge | ||||
United States of America</t> | ||||
<t>Email: charliep@computer.org</t> | ||||
<t>Jakub Horn | ||||
Cisco Systems, Inc. | ||||
United States of America</t> | ||||
<t>Email: jakuhorn@cisco.com</t> | ||||
</section> | ||||
<!-- End section "Contributors" --> | ||||
<section anchor="acknowledge" numbered="true" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors would like to thank Daisuke Yokota, Bart Peirens, | ||||
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, | ||||
Francois Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, | ||||
Ravi Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo | ||||
and Jeffrey Zhang for their useful comments of this work.</t> | ||||
</section> | ||||
<!-- End section "Acknowledgements" --> | ||||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="I-D.ietf-spring-sr-service-programming" to="SR-SERV-PR | ||||
OG"/> | ||||
<displayreference target="I-D.camarilloelmalky-springdmm-srv6-mob-usecases" to=" | ||||
SRV6-MOB-USECASES"/> | ||||
<displayreference target="I-D.ali-teas-spring-ns-building-blocks" to="NETWORK-SL | ||||
ICE"/> | ||||
<displayreference target="I-D.mhkk-dmm-srv6mup-architecture" to="MUP-SR-ARCH"/> | ||||
<displayreference target="I-D.matsushima-spring-srv6-deployment-status" to="SRV6 | ||||
-DEPLOY-STAT"/> | ||||
<displayreference target="I-D.kohno-dmm-srv6mob-arch" to="SRV6-MOB-ARCH-DISCUSS" | ||||
/> | ||||
<displayreference target="I-D.gundavelli-dmm-mfa" to="MFA"/> | ||||
<displayreference target="I-D.murakami-dmm-user-plane-message-encoding" to="SRV6 | ||||
-UP-MSG-ENCODING"/> | ||||
<displayreference target="I-D.ietf-spring-srv6-srh-compression" to="SRV6-SRH-COM | ||||
PRESSION"/> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8402.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8402.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8986.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8986.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8754.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8754.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9256.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9256.xml"/> | |||
skipping to change at line 1335 ¶ | skipping to change at line 1499 ¶ | |||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8402.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8402.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8986.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8986.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8754.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8754.xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9256.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9256.xml"/> | |||
<reference anchor="TS.23501"> | <reference anchor="TS.23501"> | |||
<front> | <front> | |||
<title>System Architecture for the 5G System</title> | <title>System architecture for the 5G System (5GS)</title> | |||
<author surname="3GPP" fullname="3GPP"> | <author> | |||
<organization>3GPP</organization> | ||||
</author> | </author> | |||
<date month="November" year="2017"/> | <date month="June" year="2023"/> | |||
</front> | </front> | |||
<seriesInfo name="3GPP TS 23.501" value="15.0.0"/> | <seriesInfo name="3GPP TS" value="23.501"/> | |||
<refcontent>Version 17.9.0</refcontent> | ||||
</reference> | </reference> | |||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9087.xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9087.xml"/> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ls | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
r-flex-algo.xml"/> | FC.9350.xml"/> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-sp | ||||
ring-sr-service-programming.xml"/> | <!-- [I-D.ietf-spring-sr-service-programming] IESG state I-D Exists. Updated to | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-camaril | long version because missing editor role for Clad and Xu. --> | |||
loelmalky-springdmm-srv6-mob-usecases.xml"/> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ali-spr | <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datat | |||
ing-network-slicing-building-blocks.xml"/> | racker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-07"> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mhkk-dm | <front> | |||
m-srv6mup-architecture.xml"/> | <title>Service Programming with Segment Routing</title> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-matsush | <author initials="F." surname="Clad" fullname="Francois Clad" role="editor"> | |||
ima-spring-srv6-deployment-status.xml"/> | <organization>Cisco Systems, Inc.</organization> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-kohno-d | </author> | |||
mm-srv6mob-arch.xml"/> | <author initials="X." surname="Xu" fullname="Xiaohu Xu" role="editor"> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-gundave | <organization>China Mobile</organization> | |||
lli-dmm-mfa.xml"/> | </author> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-murakam | <author initials="C." surname="Filsfils" fullname="Clarence Filsfils"> | |||
i-dmm-user-plane-message-encoding.xml"/> | <organization>Cisco Systems, Inc.</organization> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-sp | </author> | |||
ring-srv6-srh-compression.xml"/> | <author initials="D." surname="Bernier" fullname="Daniel Bernier"> | |||
<organization>Bell Canada</organization> | ||||
</author> | ||||
<author initials="C." surname="Li" fullname="Cheng Li"> | ||||
<organization>Huawei</organization> | ||||
</author> | ||||
<author initials="B." surname="Decraene" fullname="Bruno Decraene"> | ||||
<organization>Orange</organization> | ||||
</author> | ||||
<author initials="S." surname="Ma" fullname="Shaowen Ma"> | ||||
<organization>Mellanox</organization> | ||||
</author> | ||||
<author initials="C." surname="Yadlapalli" fullname="Chaitanya Yadlapalli"> | ||||
<organization>AT&T</organization> | ||||
</author> | ||||
<author initials="W." surname="Henderickx" fullname="Wim Henderickx"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<author initials="S." surname="Salsano" fullname="Stefano Salsano"> | ||||
<organization>Universita di Roma "Tor Vergata"</organization> | ||||
</author> | ||||
<date month="February" day="15" year="2023"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programmin | ||||
g-07"/> | ||||
</reference> | ||||
<!-- [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] IESG state Expired. Upda | ||||
ted to long version because missing editor role for Camarillo and Elmalky. --> | ||||
<reference anchor="I-D.camarilloelmalky-springdmm-srv6-mob-usecases" target="htt | ||||
ps://datatracker.ietf.org/doc/html/draft-camarilloelmalky-springdmm-srv6-mob-use | ||||
cases-02"> | ||||
<front> | ||||
<title>SRv6 Mobility Use-Cases</title> | ||||
<author initials="P." surname="Camarillo" fullname="Pablo Camarillo" role="edito | ||||
r"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author initials="H." surname="Elmalky" fullname="Hani Elmalky" role="editor"> | ||||
<organization>Individual</organization> | ||||
</author> | ||||
<author initials="S." surname="Matsushima" fullname="Satoru Matsushima"> | ||||
<organization>SoftBank</organization> | ||||
</author> | ||||
<author initials="D." surname="Voyer" fullname="Daniel Voyer"> | ||||
<organization>Bell Canada</organization> | ||||
</author> | ||||
<author initials="A." surname="Cui" fullname="Anna Cui"> | ||||
<organization>AT&T</organization> | ||||
</author> | ||||
<author initials="B." surname="Peirens" fullname="Bart Peirens"> | ||||
<organization>Proximus</organization> | ||||
</author> | ||||
<date month="August" day="15" year="2019"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-camarilloelmalky-springdmm-srv6-m | ||||
ob-usecases-02"/> | ||||
</reference> | ||||
<!-- [I-D.ali-teas-spring-ns-building-blocks] IESG state Expired --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. | ||||
ali-teas-spring-ns-building-blocks.xml"/> | ||||
<!-- [I-D.mhkk-dmm-srv6mup-architecture] IESG state I-D Exists --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. | ||||
mhkk-dmm-srv6mup-architecture.xml"/> | ||||
<!-- [I-D.matsushima-spring-srv6-deployment-status] IESG state Expired --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. | ||||
matsushima-spring-srv6-deployment-status.xml"/> | ||||
<!-- [I-D.kohno-dmm-srv6mob-arch] IESG state Exists. Updated to long version bec | ||||
ause xi:include shows March 12, 2023, as the date when it's axtually march 9, 20 | ||||
23 --> | ||||
<reference anchor="I-D.kohno-dmm-srv6mob-arch" target="https://datatracker.ietf. | ||||
org/doc/html/draft-kohno-dmm-srv6mob-arch-06"> | ||||
<front> | ||||
<title>Architecture Discussion on SRv6 Mobile User plane</title> | ||||
<author initials="M." surname="Kohno" fullname="Miya Kohno"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author initials="F." surname="Clad" fullname="Francois Clad"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author initials="P." surname="Camarillo" fullname="Pablo Camarillo"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author initials="Z." surname="Ali" fullname="Zafar Ali"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<date month="March" day="9" year="2023"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-kohno-dmm-srv6mob-arch-06"/> | ||||
</reference> | ||||
<!-- [I-D.gundavelli-dmm-mfa] IESG state Expired --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. | ||||
gundavelli-dmm-mfa.xml"/> | ||||
<!-- [I-D.murakami-dmm-user-plane-message-encoding] IESG state Expired --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. | ||||
murakami-dmm-user-plane-message-encoding.xml"/> | ||||
<!-- [I-D.ietf-spring-srv6-srh-compression] IESG state I-D Exists. Updated to lo | ||||
ng version because missing editor role for Cheng and Clad--> | ||||
<reference anchor="I-D.ietf-spring-srv6-srh-compression" target="https://datatra | ||||
cker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-05"> | ||||
<front> | ||||
<title>Compressed SRv6 Segment List Encoding in SRH</title> | ||||
<author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor"> | ||||
<organization>China Mobile</organization> | ||||
</author> | ||||
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author initials="Z." surname="Li" fullname="Zhenbin Li"> | ||||
<organization>Huawei Technologies</organization> | ||||
</author> | ||||
<author initials="B." surname="Decraene" fullname="Bruno Decraene"> | ||||
<organization>Orange</organization> | ||||
</author> | ||||
<author initials="F." surname="Clad" fullname="Francois Clad" role="editor"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<date month="June" day="20" year="2023"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression- | ||||
05"/> | ||||
</reference> | ||||
<reference anchor="TS.29281"> | <reference anchor="TS.29281"> | |||
<front> | <front> | |||
<title>General Packet Radio System (GPRS) Tunnelling Protocol User P lane (GTPv1-U)</title> | <title>General Packet Radio System (GPRS) Tunnelling Protocol User P lane (GTPv1-U)</title> | |||
<author surname="3GPP" fullname="3GPP"> | <author> | |||
<organization>3GPP</organization> | ||||
</author> | </author> | |||
<date month="December" year="2017"/> | <date month="September" year="2022"/> | |||
</front> | </front> | |||
<seriesInfo name="3GPP TS 29.281" value="15.1.0"/> | <seriesInfo name="3GPP TS" value="29.281"/> | |||
<refcontent>Version 17.4.0</refcontent> | ||||
</reference> | </reference> | |||
<reference anchor="TS.38415"> | <reference anchor="TS.38415"> | |||
<front> | <front> | |||
<title>Draft Specification for 5GS container (TS 38.415)</title> | <title>PDU session user plane protocol</title> | |||
<author surname="3GPP" fullname="3GPP"> | <author> | |||
<organization>3GPP</organization> | ||||
</author> | </author> | |||
<date month="August" year="2017"/> | <date month="April" year="2022"/> | |||
</front> | </front> | |||
<seriesInfo name="3GPP R3-174510" value="0.0.0"/> | <seriesInfo name="3GPP TS" value="38.415"/> | |||
<refcontent>Version 17.0.0</refcontent> | ||||
</reference> | </reference> | |||
</references> | </references> | |||
</references> | </references> | |||
<section anchor="Implementations" numbered="true" toc="default"> | ||||
<name>Implementations</name> | <section anchor="acknowledge" numbered="false" toc="default"> | |||
<t>RFC Editor: Please remove this section prior to publication.</t> | <name>Acknowledgements</name> | |||
<t>This document introduces new SRv6 Endpoint Behaviors. These behaviors h | <t>The authors would like to thank <contact fullname="Daisuke Yokota"/>, | |||
ave an | <contact fullname="Bart Peirens"/>, <contact fullname="Ryokichi | |||
open-source P4 implementation available in | Onishi"/>, <contact fullname="Kentaro Ebisawa"/>, <contact | |||
<eref target="https://github.com/ebiken/p4srv6"/>.</t> | fullname="Peter Bosch"/>, <contact fullname="Darren Dukes"/>, <contact | |||
<t>Additionally, a full open-source implementation of this document is ava | fullname="Francois Clad"/>, <contact fullname="Sri Gundavelli"/>, | |||
ilable in Linux Foundation FD.io VPP project since release 20.05. More informati | <contact fullname="Sridhar Bhaskaran"/>, <contact fullname="Arashmid | |||
on available here: | Akhavain"/>, <contact fullname="Ravi Shekhar"/>, <contact | |||
<eref target="https://docs.fd.io/vpp/20.05/d7/d3c/srv6_mobile_plugin_doc.htm | fullname="Aeneas Dodd-Noble"/>, <contact fullname="Carlos Jesus | |||
l"/>.</t> | Bernardos"/>, <contact fullname="Dirk von Hugo"/>, and <contact | |||
<t>There are also experimental implementations in M-CORD NGIC and Open Air | fullname="Jeffrey Zhang"/> for their useful comments of this work.</t> | |||
Interface (OAI).</t> | ||||
</section> | </section> | |||
<!-- End section "Implementations" --> | ||||
</back> | <section numbered="false" toc="default"> | |||
</rfc> | <name>Contributors</name> | |||
<contact fullname="Kentaro Ebisawa"> | ||||
<organization>Toyota Motor Corporation</organization> | ||||
<address> | ||||
<postal> | ||||
<country>Japan</country> | ||||
</postal> | ||||
<email>ebisawa@toyota-tokyo.tech</email> | ||||
</address> | ||||
</contact> | ||||
<contact fullname="Tetsuya Murakami" > | ||||
<organization>Arrcus, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>tetsuya.ietf@gmail.com</email> | ||||
</address> | ||||
</contact> | ||||
<contact fullname="Charles E. Perkins" > | ||||
<organization>Lupin Lodge</organization> | ||||
<address> | ||||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>charliep@computer.org</email> | ||||
</address> | ||||
</contact> | ||||
<contact fullname="Jakub Horn" > | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>jakuhorn@cisco.com</email> | ||||
</address> | ||||
</contact> | ||||
</section> | ||||
</back> </rfc> | ||||
End of changes. 227 change blocks. | ||||
932 lines changed or deleted | 1114 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |