Re: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13
"Pablo Camarillo \(pcamaril\)" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <DM8PR11MB5719C2A21EF7D42221E3DBB5C9E59@DM8PR11MB5719.namprd11.prod.outlook.com> |
Hi Jeffrey, Inline with PC3. I'm also attaching the diff that we will be pushing once the I-D submission tool reopens. It includes the changes agreed to in our previous emails. Thanks, Pablo. -----Original Message----- From: Jeffrey (Zhaohui) Zhang <[email protected]> Sent: jueves, 22 de julio de 2021 21:00 To: Pablo Camarillo (pcamaril) <[email protected]> Cc: [email protected] Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13 Hi Pablo, Please see zzh2> below. -----Original Message----- From: Pablo Camarillo (pcamaril) <[email protected]> Sent: Thursday, July 22, 2021 1:27 PM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: [email protected] Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13 [External Email. Be cautious of content] Hi Jeffrey, Inline with PC2. Thanks, Pablo. -----Original Message----- From: dmm <[email protected]> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: jueves, 22 de julio de 2021 16:36 To: Pablo Camarillo (pcamaril) <[email protected]> Cc: [email protected] Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13 Hi Pablo, Please see zzh> below. -----Original Message----- From: Pablo Camarillo (pcamaril) <[email protected]> Sent: Wednesday, July 21, 2021 1:37 PM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: Sri Gundavelli (sgundave) <[email protected]>; [email protected] Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13 [External Email. Be cautious of content] Hi Jeffrey, Many thanks for the summary of the open items. See inline with [PC]. Cheers, Pablo. > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang <[email protected]> > Sent: miércoles, 14 de julio de 2021 21:56 > To: Sri Gundavelli (sgundave) <[email protected]>; Pablo Camarillo > (pcamaril) <[email protected]> > Cc: [email protected] > Subject: RE: [DMM] Additional questions/comments on > draft-ietf-dmm-srv6- > mobile-uplane-13 > > Hi, > > Here is my summary. > > General comments: > > 1. There were some architecture discussions about > SRv6-transporting-GTPu vs SRv6-replacing-GTPu. I understand that this > document is about SRv6-replacing- GTPu and the other is out of scope. That's ok - but the draft should omit "3. > Motivation" and just have an informational reference to > draft-kohno-dmm- srv6mob-arch. In other words, defer the motivation > discussion to the separate draft and just focus on technical details > in this spec. BTW - I want to clarify here that when I said "the only > advantage of SRv6-replacing-GTPu is MTU savings" is *in comparison* to SRv6-transporting-GTPu. [PC] I have mixed feelings about removing the Section 3(Motivation). [PC] Stating a couple of paragraphs of motivation is useful to the reader, while -if they want details- then they could jump to the draft-kohno for the specifics. [PC] That said, I also see the point that a Standards Track document should only focus on the technical details and do not discuss such things. [PC] I'm fine either way (remove or keep). I don't have any preference. I'm the document editor: I'll edit the document to whatever the WG prefers. > 2. I don't think it is good to categorize into "traditional mode" and > "enhanced mode" (note that I am not saying that an operator does not > have a choice in what it wants to deploy - it's just that the > categorization itself is strange), though that's not technically critical. [PC] As the I-D states " The traditional mode minimizes the changes required to the mobile system; hence it is a good starting point for forming a common ground." [PC] Since 2017 the wg guidance/consensus was to have these two modes for that reason above. > 3. draft-murakami-dmm-user-plane-message-encoding should be a > normative reference. [PC] I believe it's fine as an informative reference. One could implement this draft without draft-murakami. (While I agree with you that it will be common to implement both) Zzh> Let me take one step back. Zzh> This spec includes an option where SRv6 encapsulation/decapsulation Zzh> based on N2/N4-signaled GTP-U parameters, so I thought there must be a spec about how the GTP-U header fields are encoded in SRv6. If draft-murakami is that draft, then it must be a normative reference. If draft-murakami is not that draft, then either all details need to be spelled out in this document, or some other document should be referenced (normatively). Zzh> It seems that you're saying draft-murakmi is a separate/parallel thing. If so, which spec talks about how the GTP extension headers, sequence number, N-PDU number are encoded? If those are not expected to be used/supported, it needs to be pointed out. [PC2] None of those additional GTP-U parameters are included in the SRv6 encapsulation defined in this document. Zzh2> I think that should be pointed out explicitly. [PC3] Added. [PC2] The N2/N4-signaled GTP-U parameters are combined with a local policy to steer on a SID list. If you want to encode the additional parameters, then this is out of the scope of this document. Informative reference to draft-murakami provides one possible encoding. + 0-2 3 4 5 6 7 8-15 16-23 24-31 0 Version Protocol type Reserved Extension Header Flag Sequence Number Flag N-PDU Number Flag Message Type Message length 32 TEID 64 Sequence number N-PDU number Next extension header type > > Specific outstanding technical comments: > > 4. In 5.3, for uplink traffic, the GW has End.M.GTP6.D for the UPF > address B and the gNB does not need to know the existence of GW. For > downlink traffic, the UPF knows there is a GW and put the GW::TEID in > the SRH. Why not make GW invisible to UPF as well and just use > gNB::TEID, and then have gNB/96 as End.M.GTP6.E on the SRGW? You can > still put GW in the SRH to steer traffic through the GW. [PC] Replied in the other thread. Zzh> I did not see it there? [PC2] I got confused to the other point. Indeed it wasn't replied. [PC2] The address B in the uplink is a BindingSID at the SRGW. It is not a SID belonging to the UPF as you state in your first sentence. Zzh2> My point is to use a loopback address on the UPF instead of the SRGW - that way the GW is completely transparent to others (like in the other direction). That does not prevent the SRGW from having a binding SID for it. Zzh2> Once you do that, we can actually get rid of one endpoint behavior (I'll talk about that separately). [PC3] Using a BSID at the SRGW provides you several benefits: 1) You can combine it with FlexAlgo and have SLA before reaching the SRGW; 2) At the SRGW you want to apply the SR policy as soon as possible to allow VNFs before the UPF. [PC3] Using an address of the UPF does not provide any benefit, and quite the contrary, adds extra complexity as you need to manage several addresses on the UPF, one per SLA. > 5. In 5.2.2, because of the END.DX2/4/6 behavior on gNB, the SID list > and S1_out can't just simply use gNB. It must be gNB:TEID. [PC] Replied in the other thread. TEID is not present. It is a specific SID instance. Zzh> I also replied there. > 6. I still don't agree with the aggregation statement in 5.2.3. Per > 5.2.2 (and see > #5 above), the gNB does END.DX2/4/6 so per-UE SID (based on > N2/4-signaled > TEID) is needed. Otherwise, gNB needs to forward traffic based on > inner header (UE address), which is different from both 5.2.2 and > normal gNB behavior. [PC] I don't follow your point. You have stated in previous emails that aggregation can be done, hence I don't understand which part of the statement you disagree with. "Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 replacing GTP-U." https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmm/Fv98rJ_PLyg5PNrQdnOa8g-1-EQ/__;!!NEt6yMaO-gk!TtoDf0I3B72KdJ0dz3B-TP46AGXDxJNcJ1LVz5UAFrW--mj0qmI4qbK0gdw9oFfR$ zzh> Let's look at the text here: The Enhanced Mode improves since it allows the aggregation of several UEs under the same SID list. For example, in the case of stationary residential meters that are connected to the same cell, all such devices can share the same SID list. This improves scalability compared to Traditional Mode (unique SID per UE) and compared to GTP-U (dedicated TEID per UE). Zzh> Unless gNB does inner (UE) address lookup to forward traffic, you have to use unique SID per UE. This means that, the aggregation is *not provided by SRv6-replacing-GTP". It is provided by upgraded gNB function (that is not 3GPP-defined) that does inner address lookup and completely independent of SRv6. Zzh> If the "improved scalability" refers to that a single SID is used to reach many UEs, then GTP-U (legacy or SRv6-transported) already has that from day-one (only the gNB address is used). Zzh> I do agree that when gNB does inner address lookup for forwarding, then aggregation is achieved compared to traditional mode in 5.1. That's also why I suggested from early on that the main distinction of enhanced mode is this aggregation (not the traffic steering and service programming). But the spec should be explicit that this is done by inner address lookup. However, with aggregation then section 5.2.2 is incorrect because it talks about End.DX2/4/6 with gNB address - how can you do End.DX2/4/6 without per-UE SIDs? [PC2] GTP-U today does not allow to perform aggregation. Please point me to the relevant 3GPP standard if I'm wrong. Zzh2> You were saying "all such devices can share the same SID list" (vs. different SIDs on the gNB). But with GTP-U, there is only gNB address in the first place - it’s aggregation by default. [PC3] The amount of state to hold in GTP-U is the combination of {IP, TEID} tuples. In SRv6 it is the number of unique SID lists. In GTP-U there is no aggregation -you could change the spec it if you want, but today there is none-. In SRv6 traditional mode there is no aggregation at all -a unique SID list per UE-. Therefore the state in those two solutions is exactly the same. In Enhanced mode you reuse the same SID list for several UE, hence the scalability improvement. [PC2] You may have aggregation on the uplink and on the downlink. I believe your point is particularly on the downlink (as you have already recognized uplink is doable). Zzh2> For uplink, either you need to use different B addresses on UPF, Zzh2> or you still have to include TEID somewhere so that UPF knows Zzh2> where to do lookup for the inner address. It is true that this can Zzh2> be done by local policy on gNB, but the same can be done for GTP Zzh2> as well. You can say that GTP is out of scope and that's fine, but Zzh2> don't claim this is an advantage over GTP 😊 [PC3] Can you please point me to the relevant 3GPP spec that allows to do aggregation for GTP? Zzh2> In short, my points are: a) there are implications to do aggregation and they should be spelled out; b) the same can be done for GTP as well - not SRv6 specific. [PC2] You have various methods or forms to perform the downlink aggregation. [PC2] One of them is to do an inner address lookup. In such case you are indeed right that instead of using End.DX2/DX4/DX6, the DT4/DT6/DT2 should be used. [PC2] Another option is to forward to the group of UEs and let the UE drop the packet based on the IP destination address. Zzh2> To claim the aggregation advantages, these need to be spelled out. [PC3] Added in the rev14. > 7. (this is new) 5.2.2 says " gNB's control plane associates that > session from the > UE(A) with the IPv6 address B. gNB's control plane does a lookup on B > to find the related SID list <S1, C1, U2::1> ... When the packet > arrives at UPF2, the active segment (U2::1) is an > End.DT4/End.DT6/End.DT2U". End.DT4/6/2U requires specific tables for > lookup (to go to different DNs in this case) and the text is not clear > on how that table is determined. Different UEs could be associated > with different DNs but the N2 signaling can give the same IPv6 address > B. In GTP-U case, the UPF is able to associate different UEs to > different DNs based on TEID but for SRv6 different mechanism is needed > (and missing for now). It could be that the control plane will give out different address B for different DNs but that needs to be spelled out. Zzh> What about this one? [PC2] You are right, the control plane needs to ensure consistency when doing SID advertisements. That said, I don't see why such control plane consideration should be added to this document given that this document focuses on the dataplane and control plane is out of the scope of this document. Zzh2> The implications to the control plane should be pointed out at high level in this document (e.g. the control plane will give out different address B for different DNs). [PC3] In the same way than in a VPN we have a different label for each different tenant. There's nothing particular about it... > > There may be other minor points/nits. For example, 5.1 says N2/N4 is > unchanged while 5.2 only says N2 is unchanged. Does 5.2 imply/need N4 > change? Good to be explicit. [PC] Control-plane is out of the scope of this document. Zzh> Like in 5.1 saying that N2/N4 is unchanged, 5.2 should be explicit if N4 is changed. Zzh> Details of changes can be out of scope of this document, but a) there must be a referenced document talking about it; b) it's good to talk about the changes at high level (e.g., different addresses B is given out) in this document. [PC2] It is already stated in 5.2 (fourth paragraph). Text only talks about N2. I will add N4. > > BTW - while trying to confirm whether N4 needs to be changed for 5.2, > I noticed the following in section 9: > > The control plane could be the current 3GPP-defined control plane > with slight modifications to the N4 interface [TS.29244]. > > It should be clarified what kind of modifications to the N4 is needed > and for what scenario. [PC] Control-plane is out of the scope of this document. Section 9 provides some considerations, and refers to some technologies that could be used. I don't think any further text should be added -quite the contrary, we should remove-. Zzh> If a solution relies on changed control plane, the changes must be talked somewhere. If it is not in this document, then a reference should be provided. [PC2] I will replace the entire section 9 by the following: <OLD> 9. Control Plane Considerations This document focuses on user-plane behavior and its independence from the control plane. The control plane could be the current 3GPP-defined control plane with slight modifications to the N4 interface [TS.29244]. zzh2> The slight modifications should be pointed out at high level in this document; Details should be specified in some document that is referenced to in this document. [PC3] Analogy: RFC8986 does not have any reference to neither the ISIS-SRv6 I-D, nor the BGP-SRv6 drafts. And actually, the IESG was the one asking to remove those references. I don't see why it should be different in this case. zzh2> Otherwise, this is like a controller based network w/o standard signaling from the controller and not implementable. Zzh2> Jeffrey Alternatively, SRv6 could be used in conjunction with a new mobility control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes and its applicability to an SRv6 user-plane is out of the scope of this document. Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for the new behaviors defined in this document. </OLD> <NEW> 9. Control Plane Considerations This document focuses on user-plane behavior and its independence from the control plane. While there are benefits in an enhanced control plane, this document does not impose any change to it. Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for the new behaviors defined in this document to be used by a control plane if needed. </NEW> Zzh> Jeffrey > > Jeffrey > > -----Original Message----- > From: dmm <[email protected]> On Behalf Of Sri Gundavelli > (sgundave) > Sent: Wednesday, July 7, 2021 2:59 PM > To: Pablo Camarillo (pcamaril) <[email protected]> > Cc: [email protected] > Subject: Re: [DMM] Additional questions/comments on > draft-ietf-dmm-srv6- > mobile-uplane-13 > > [External Email. Be cautious of content] > > > Authors: > > Can you please summarize the discussions and identify the open issues, > or areas of non-agreement that have come up as part of this WGCLC > > Thanks > Sri > > > > _______________________________________________ > dmm mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;! > !NEt6yMaO-gk!RHnpE1MQpMxwvVzdJxpCZjAUFz5bvXIR6cIWkZ21QDqH- > Jv91pT-qaf5U6u-eMJx$ > > Juniper Business Use Only > > Juniper Business Use Only Juniper Business Use Only Juniper Business Use Only _______________________________________________ dmm mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!TBkcHZoTGAsJLktHtw_FIcrUCxwrvpD8oFODkgBc-W6j6JW8yl7QflO-sYu7bf-m$ Juniper Business Use Only Juniper Business Use Only _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
draft-ietf-dmm-srv6-mobile-uplane.txt
(text/plain, 66.6 KB)
DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils
Expires: January 24, 2022 M. Kohno
P. Camarillo, Ed.
Cisco Systems, Inc.
D. Voyer
Bell Canada
C. Perkins
Lupin Lodge
July 23, 2021
Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-14
Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature
of SRv6 accomplishes mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility, end-to-end network slicing, and
SLA control for various applications. This document describes the
SRv6 mobile user plane.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 24, 2022.
Matsushima, et al. Expires January 24, 2022 [Page 1]
Internet-Draft SRv6 Mobile User-Plane July 2021
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9
5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11
5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 12
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 18
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24
6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25
6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26
8. Network Slicing Considerations . . . . . . . . . . . . . . . 27
Matsushima, et al. Expires January 24, 2022 [Page 2]
Internet-Draft SRv6 Mobile User-Plane July 2021
9. Control Plane Considerations . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
In mobile networks, mobility management systems provide connectivity
over a wireless link to stationary and non-stationary nodes. The
user-plane establishes a tunnel between the mobile node and its
anchor node over IP-based backhaul and core networks.
This document shows the applicability of SRv6 (Segment Routing IPv6)
to mobile networks.
Segment Routing [RFC8402] is a source routing architecture: a node
steers a packet through an ordered list of instructions called
"segments". A segment can represent any instruction, topological or
service based.
SRv6 applied to mobile networks enables a source-routing based mobile
architecture, where operators can explicitly indicate a route for the
packets to and from the mobile node. The SRv6 Endpoint nodes serve
as mobile user-plane anchors.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
o CNF: Cloud-native Network Function
o NFV: Network Function Virtualization
o PDU: Packet Data Unit
o PDU Session: Context of a UE connects to a mobile network.
o UE: User Equipment
o UPF: User Plane Function
o VNF: Virtual Network Function (including CNFs)
Matsushima, et al. Expires January 24, 2022 [Page 3]
Internet-Draft SRv6 Mobile User-Plane July 2021
The following terms used within this document are defined in
[RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding
SID.
The following terms used within this document are defined in
[RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
Node and Reduced SRH.
The following terms used within this document are defined in
[RFC8986]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment
Endpoint Behavior.
2.2. Conventions
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 visit, and S3 is the last SID to visit along the SR path.
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
- Source Address is SA, Destination Address is DA, and next-header is
SRH
- SRH with SID list <S1, S2, S3> with Segments Left = SL
- 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.
- The payload of the packet is omitted.
SRH[n]: A shorter representation of Segment List[n], as defined in
[RFC8754]. SRH[SL] can be different from the DA of the IPv6 header.
o gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2.
2.3. Predefined SRv6 Endpoint Behaviors
The following SRv6 Endpoint Behaviors are defined in [RFC8986].
o End.DT4: Decapsulation and Specific IPv4 Table Lookup
Matsushima, et al. Expires January 24, 2022 [Page 4]
Internet-Draft SRv6 Mobile User-Plane July 2021
o End.DT6: Decapsulation and Specific IPv6 Table Lookup
o End.DT46: Decapsulation and Specific IP Table Lookup
o End.DX4: Decapsulation and IPv4 Cross-Connect
o End.DX6: Decapsulation and IPv6 Cross-Connect
o End.DX2: Decapsulation and L2 Cross-Connect
o End.T: Endpoint with specific IPv6 Table Lookup
This document defines new SRv6 Segment Endpoint Behaviors in
Section 6.
3. Motivation
Mobile networks are becoming more challenging to operate. On one
hand, traffic is constantly growing, and latency requirements are
tighter; on the other-hand, there are new use-cases like distributed
NFVi that are also challenging network operations.
The current architecture of mobile networks does not take into
account the underlying transport. The user-plane is rigidly
fragmented into radio access, core and service networks, connected by
tunneling according to user-plane roles such as access and anchor
nodes. These factors have made it difficult for the operator to
optimize and operate the data-path.
In the meantime, applications have shifted to use IPv6, and network
operators have started adopting IPv6 as their IP transport. SRv6,
the IPv6 dataplane instantiation of Segment Routing [RFC8402],
integrates both the application data-path and the underlying
transport layer into a single protocol, allowing operators to
optimize the network in a simplified manner and removing forwarding
state from the network. It is also suitable for virtualized
environments, like VNF/CNF to VNF/CNF networking. SRv6 has been
deployed in dozens of networks
[I-D.matsushima-spring-srv6-deployment-status].
SRv6 defines the network-programming concept [RFC8986]. Applied to
mobility, SRv6 can provide the user-plane behaviors needed for
mobility management. SRv6 takes advantage of the underlying
transport awareness and flexibility together with the ability to also
include services to optimize the end-to-end mobile dataplane.
The use-cases for SRv6 mobility are discussed in
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
Matsushima, et al. Expires January 24, 2022 [Page 5]
Internet-Draft SRv6 Mobile User-Plane July 2021
4. 3GPP Reference Architecture
This section presents a reference architecture and possible
deployment scenarios.
Figure 1 shows a reference diagram from the 5G packet core
architecture [TS.23501].
The user plane described in this document does not depend on any
specific architecture. The 5G packet core architecture as shown is
based on the latest 3GPP standards at the time of writing this draft.
+-----+
| AMF |
/+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
Figure 1: 3GPP 5G Reference Architecture
o UE: User Endpoint
o gNB: gNodeB with N3 interface towards packet core (and N2 for
control plane)
o UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)
o UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane)
o SMF: Session Management Function
o AMF: Access and Mobility Management Function
o DN: Data Network e.g. operator services, Internet access
This reference diagram does not depict a UPF that is only connected
to N9 interfaces, although the mechanisms defined in this document
also work in such case.
Each session from a UE gets assigned to a UPF. Sometimes multiple
UPFs may be used, providing richer service functions. A UE gets its
IP address from the DHCP block of its UPF. The UPF advertises that
IP address block toward the Internet, ensuring that return traffic is
routed to the right UPF.
Matsushima, et al. Expires January 24, 2022 [Page 6]
Internet-Draft SRv6 Mobile User-Plane July 2021
5. User-plane behaviors
This section introduces an SRv6 based mobile user-plane.
In order to simplify the adoption of SRv6, we present two different
"modes" that vary with respect to the use of SRv6. The first one is
the "Traditional mode", which inherits the current 3GPP mobile
architecture. In this mode GTP-U protocol [TS.29281] is replaced by
SRv6, however the N3, N9 and N6 interfaces are still point-to-point
interfaces with no intermediate waypoints as in the current mobile
network architecture.
The second mode is the "Enhanced mode". This is an evolution from
the "Traditional mode". In this mode the N3, N9 or N6 interfaces
have intermediate waypoints -SIDs- that are used for Traffic
Engineering or VNF purposes. This results in optimal end-to-end
policies across the mobile network with transport and services
awareness.
In both, the Traditional and the Enhanced modes, we assume that the
gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6
interfaces are SRv6).
In addition to those two modes, we introduce two mechanisms for
interworking with legacy access networks (those where the N3
interface is unmodified). In this document we introduce them as a
variant to the Enhanced mode, however they are equally applicable to
the Traditional mode.
One of these mechanisms is designed to interwork with legacy gNBs
using GTP/IPv4. The second mechanism is designed to interwork with
legacy gNBs using GTP/IPv6.
This document uses SRv6 Segment Endpoint Behaviors defined in
[RFC8986] as well as new SRv6 Segment Endpoint Behaviors designed for
the mobile user plane that are defined in this document in Section 6.
5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged
with the sole exception of the use of SRv6 as the data plane instead
of GTP-U. There is no impact to the rest of the mobile system.
In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
here to replace GTP encapsulation with the SRv6 encapsulation, while
not changing anything else. There will be a unique SRv6 SID
Matsushima, et al. Expires January 24, 2022 [Page 7]
Internet-Draft SRv6 Mobile User-Plane July 2021
associated with each PDU Session, and the SID list only contains a
single SID.
The traditional mode minimizes the changes required to the mobile
system; hence it is a good starting point for forming a common
ground.
The gNB/UPF control-plane (N2/N4 interface) is unchanged,
specifically a single IPv6 address is provided to the gNB. The same
control plane signalling is used, and the gNB/UPF decides to use SRv6
based on signaled GTP-U parameters per local policy. The only
information from the GTP-U parameters used for the SRv6 policy is the
TEID and the IPv6 Destination Address.
Our example topology is shown in Figure 2. In traditional mode the
gNB and the UPFs are SR-aware. In the descriptions of the uplink and
downlink packet flow, A is an IPv6 address of the UE, and Z is an
IPv6 address reachable within the Data Network DN. A new SRv6
Endpoint Behavior, End.MAP, defined in Section 6.2, is used.
________
SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - example topology
5.1.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs a
H.Encaps.Red operation. Since there is only one SID, there is no
need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
U1::1. U1::1 represents an anchoring SID specific for that session
at UPF1. gNB obtains the SID U1::1 from the existing control plane
(N2 interface).
When the packet arrives at UPF1, the SID U1::1 is associated with the
End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1,
that belongs to the next UPF (U2).
Matsushima, et al. Expires January 24, 2022 [Page 8]
Internet-Draft SRv6 Mobile User-Plane July 2021
When the packet arrives at UPF2, the SID U2::1 corresponds to an
End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates
the packet, performs a lookup in a specific table associated with
that mobile network and forwards the packet toward the data network
(DN).
5.1.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A)
UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2
When the packet arrives at the UPF2, the UPF2 maps that flow into a
PDU Session. This PDU Session is associated with the segment
endpoint <U1::2>. UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with no SRH since
there is only one SID.
Upon packet arrival on UPF1, the SID U1::2 is a local SID associated
with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next
anchoring point and replaces U1::2 by gNB::1, that belongs to the
next hop.
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 Type). The
gNB decapsulates the packet, removing the IPv6 header and all its
extensions headers, and forwards the traffic toward the UE.
5.2. Enhanced Mode
Enhanced mode improves scalability, provides traffic engineering
capabilities, and allows service programming
[I-D.ietf-spring-sr-service-programming], thanks to the use of
multiple SIDs in the SID list (instead of a direct connectivity in
between UPFs with no intermediate waypoints as in Traditional Mode).
Thus, the main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the
anchoring SIDs at UPFs.
Additionally in this mode the operator may choose to aggregate
several devices under the same SID list (e.g., stationary residential
meters connected to the same cell) to improve scalability.
Matsushima, et al. Expires January 24, 2022 [Page 9]
Internet-Draft SRv6 Mobile User-Plane July 2021
The gNB/UPF control-plane (N2/N4 interface) is unchanged,
specifically a single IPv6 address is provided to the gNB. A local
policy instructs the gNB to use SRv6.
The gNB MAY resolve the IP address received via the control plane
into a SID list using a mechanism like PCEP, DNS-lookup, LISP
control-plane or others. The resolution mechanism is out of the
scope of this document.
Note that the SIDs MAY use the arguments Args.Mob.Session if required
by the UPFs.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the
gNB and the UPF are SR-aware. The Figure shows two service segments,
S1 and C1. S1 represents a VNF in the network, and C1 represents an
intermediate router used for Traffic Engineering purposes to enforce
a low-latency path in the network. Note that neither S1 nor C1 are
required to have an N4 interface.
+----+ SRv6 _______
SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node
-| S1 |-
+----+
SRv6 node
VNF
Figure 3: Enhanced mode - Example topology
5.2.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
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)
C1_out : (gNB, U1::1)(A,Z) ->End with PSP
UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U
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 the IPv6
address B. gNB's control plane does a lookup on B to find the
related SID list <S1, C1, U1::1>.
Matsushima, et al. Expires January 24, 2022 [Page 10]
Internet-Draft SRv6 Mobile User-Plane July 2021
When gNB transmits the packet, it contains all the segments of the SR
policy. The SR policy includes segments for traffic engineering (C1)
and for service programming (S1).
Nodes S1 and C1 perform their related Endpoint functionality and
forward the packet.
When the packet arrives at UPF1, the active segment (U1::1) is an
End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing
the IPv6 header with all its extension headers) and forwards toward
the data network.
5.2.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF1_in : (Z,A) ->UPF1 maps the flow w/
SID list <C1,S1, gNB>
UPF1_out: (U1::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U1::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U1::1, gNB)(Z,A) ->End with PSP
gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2
When the packet arrives at the UPF1, the UPF1 maps that particular
flow into a UE PDU Session. This UE PDU Session is associated with
the policy <C1, S1, gNB>. The UPF1 performs a H.Encaps.Red
operation, encapsulating the packet into a new IPv6 header with its
corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the gNB, the IPv6 DA corresponds to an
End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
underlying traffic). The gNB decapsulates the packet, removing the
IPv6 header and forwards the traffic toward the UE.
Note that there are several means to provide the UE session
aggregation. The decision on which one to use is a local decision
made by the operator. One such options comprises the gNB performing
an IP lookup on the inner packet by using the End.DT4, End.DT6, and
End.DT2 behaviors. An alternative option comprises forwarding the
packet through a set of L2 adjacencies to a group of UEs, and letting
the UE discard the packets not destined to it.
Matsushima, et al. Expires January 24, 2022 [Page 11]
Internet-Draft SRv6 Mobile User-Plane July 2021
5.2.3. Scalability
The Enhanced Mode improves since it allows the aggregation of several
UEs under the same SID list. For example, in the case of stationary
residential meters that are connected to the same cell, all such
devices can share the same SID list. This improves scalability
compared to Traditional Mode (unique SID per UE) and compared to
GTP-U (dedicated TEID per UE).
5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes two mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, and another for IPv6.
In the interworking scenarios as illustrated in Figure 4, the gNB
does not support SRv6. The gNB supports GTP encapsulation over IPv4
or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is
added. The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point and maintains very little state. For
this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______
IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| SRGW |--------| UPF |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node
Figure 4: Example topology for interworking
Both of the mechanisms described in this section are applicable to
either the Traditional Mode or the Enhanced Mode.
5.3.1. Interworking with IPv6 GTP
In this interworking mode the gNB at the N3 interface uses GTP over
IPv6.
Key points:
o The gNB is unchanged (control-plane or user-plane) and
encapsulates into GTP (N3 interface is not modified).
o The 5G Control-Plane towards the gNB (N2 interface) is unmodified;
one IPv6 address is needed (i.e. a BSID at the SRGW). The SRv6
SID is different depending on the required SLA.
o In the uplink, the SRGW removes GTP, finds the SID list related to
the IPv6 DA, and adds SRH with the SID list.
Matsushima, et al. Expires January 24, 2022 [Page 12]
Internet-Draft SRv6 Mobile User-Plane July 2021
o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is
shared across UEs as long as they belong to the same context
(i.e., tenant). A set of many different policies (i.e., different
SLAs) increases the amount of state required.
o When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic
into an SR policy when it arrives at the SRGW.
An example topology is shown in Figure 5.
S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic
Engineering.
+----+
IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___
-| SRGW |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> End with PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates
the packet into IPv6, UDP, and GTP headers. The IPv6 DA B, and the
GTP TEID T are the ones received in the N2 interface.
Matsushima, et al. Expires January 24, 2022 [Page 13]
Internet-Draft SRv6 Mobile User-Plane July 2021
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 SID at the
SRGW. Hence the packet is routed to the SRGW.
When the packet arrives at the SRGW, the SRGW identifies B as an
End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes
the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its
own SRH containing the SIDs bound to the SR policy associated with
this BindingSID. There at least one instance of the End.M.GTP6.D SID
per PDU type.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
IPv6 header with all its extension headers) and forwards the packet
toward the data network.
5.3.1.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB>
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)
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
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its
corresponding SRH.
C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active
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 headers. The new IPv6 DA is the gNB which is the last SID in
the received SRH. The TEID in the generated GTP header is an
argument of the received End.M.GTP6.E SID. The SRGW pushes the
headers to the packet and forwards the packet toward the gNB. There
is one instance of the End.M.GTP6.E SID per PDU type.
Matsushima, et al. Expires January 24, 2022 [Page 14]
Internet-Draft SRv6 Mobile User-Plane July 2021
Once the packet arrives at the gNB, the packet is a regular IPv6/GTP
packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from
current and previous generations.
5.3.1.3. Scalability
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 states since
it is the UE's session anchor point.
For the uplink traffic, the state at the SRGW does not necessarily
need to be unique per PDU Session; the SR policy can be shared among
UEs. This enables more scalable SRGW deployments compared to a
solution holding millions of states, one or more per UE.
5.3.2. Interworking with IPv4 GTP
In this interworking mode the gNB uses GTP over IPv4 in the N3
interface
Key points:
o The gNB is unchanged and encapsulates packets into GTP (the N3
interface is not modified).
o In the uplink, traffic is classified by SRGW's Uplink Classifier
and steered into an SR policy. The SRGW is a UPF1 functionality
and can coexist with UPF1's Uplink Classifier functionality.
o SRGW removes GTP, finds the SID list related to DA, and adds an
SRH with the SID list.
An example topology is shown in Figure 6. In this mode the gNB is an
unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before,
the SRGW maps the IPv4/GTP traffic to SRv6.
S1 and C1 are two service segment endpoints. S1 represents a VNF in
the network, and C1 represents a router configured for Traffic
Engineering.
Matsushima, et al. Expires January 24, 2022 [Page 15]
Internet-Draft SRv6 Mobile User-Plane July 2021
+----+
IPv4/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
5.3.2.1. Packet flow - Uplink
The uplink packet flow is as follows:
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP
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)
C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates
the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B,
and the GTP TEID are the ones received at the N2 interface.
When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
Classifier rule for incoming traffic from the gNB, that steers the
traffic into an SR policy by using the function H.M.GTP4.D. The SRGW
removes the IPv4, UDP, and GTP headers and pushes an IPv6 header with
its own SRH containing the SIDs related to the SR policy associated
with this traffic. The SRGW forwards according to the new IPv6 DA.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all its extension headers) and forwards toward
the data network.
5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows:
Matsushima, et al. Expires January 24, 2022 [Page 16]
Internet-Draft SRv6 Mobile User-Plane July 2021
UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID>
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)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its
corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active
SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header
and all its extensions headers. The SRGW generates an IPv4, UDP, and
GTP headers. The IPv4 SA and DA are received as SID arguments. The
TEID in the generated GTP header is also the arguments of the
received End.M.GTP4.E SID. The SRGW pushes the headers to the packet
and forwards the packet toward the gNB.
When the packet arrives at the gNB, the packet is a regular IPv4/GTP
packet. The gNB looks for the specific radio bearer for that TEID
and forwards it on the bearer. This gNB behavior is not modified
from current and previous generations.
5.3.2.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in
the SRH pushed by the UPF2. The UPF must have this UE-base state
anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis according to an Uplink Classifier. There is state
for steering the different sessions in the form of an SR Policy.
However, SR policies are shared among several UE/sessions.
5.3.3. Extensions to the interworking mechanisms
In this section we presented two mechanisms for interworking with
gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6.
Matsushima, et al. Expires January 24, 2022 [Page 17]
Internet-Draft SRv6 Mobile User-Plane July 2021
Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the
"Traditional mode".
5.4. SRv6 Drop-in Interworking
In this section we introduce another mode useful for legacy gNB and
UPFs that still operate with GTP-U. This mode provides an
SRv6-enabled user plane in between two GTP-U tunnel endpoints.
In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and
vice-versa.
Unlike other interworking modes, in this mode both of the mobility
overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or
N9 interface to realize an intermediate SR policy.
+----+
-| S1 |-
+-----+ / +----+ \
| gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+
+-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF |
GTP[N3]\ +--------+ / +----+ +--------+ +-----+
-| SRGW-A |- SRv6 SR Gateway-B GTP
+--------+ TE
SR Gateway-A
Figure 7: Example topology for SRv6 Drop-in mode
The packet flow of Figure 7 is as follows:
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
End.M.GTP6.D.Di
SID at SRGW-A
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)
GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an
End.M.GTP6.E
SID at SRGW-B
UPF_out : (A,Z)
When a packet destined to Z is sent to the gNB, which is unmodified
(control-plane and user-plane remain GTP-U), gNB performs
encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA,
U::1, and the GTP TEID are the ones received at the N2 interface.
Matsushima, et al. Expires January 24, 2022 [Page 18]
Internet-Draft SRv6 Mobile User-Plane July 2021
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 SID at
SRGW-A. Hence the packet is routed to the SRGW.
When the packet arrives at SRGW-A, the SRGW identifies U::1 as an
End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW
removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header
with its own SRH containing the SIDs bound to the SR policy
associated with this Binding SID. There is one instance of the
End.M.GTP6.D.Di SID per PDU type.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
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
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
received SRH. The TEID in the generated GTP header is an argument of
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
the End.M.GTP6.E SID per PDU type.
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
the packet. This UPF behavior is not modified from current and
previous generations.
6. SRv6 Segment Endpoint Mobility Behaviors
6.1. Args.Mob.Session
Args.Mob.Session provide per-session information for charging,
buffering and lawful intercept (among others) required by some mobile
nodes. The Args.Mob.Session argument format is used in combination
with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2
behaviors. Note that proposed format is applicable for 5G networks,
while similar formats could be used for legacy networks.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QFI |R|U| PDU Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')|
+-+-+-+-+-+-+-+-+
Args.Mob.Session format
Matsushima, et al. Expires January 24, 2022 [Page 19]
Internet-Draft SRv6 Mobile User-Plane July 2021
o QFI: QoS Flow Identifier [TS.38415]
o R: Reflective QoS Indication [TS.23501]. This parameter indicates
the activation of reflective QoS towards the UE for the
transferred packet. Reflective QoS enables the UE to map UL User
Plane traffic to QoS Flows without SMF provided QoS rules.
o U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt.
o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID.
Arg.Mob.Session is required in case that one SID aggregates multiple
PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated
per PDU session, Args.Mob.Session helps the UPF to perform the
behaviors which require per QFI and/or per PDU Session granularity.
6.2. End.MAP
The "Endpoint behavior with SID mapping" behavior (End.MAP for short)
is used in several scenarios. Particularly in mobility, End.MAP is
used in the UPFs for the PDU Session anchor functionality.
When node N receives a packet whose IPv6 DA is S and S is a local
End.MAP SID, N does:
S01. If (IPv6 Hop Limit <= 1) {
S02. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S03. }
S04. Decrement IPv6 Hop Limit by 1
S05. Lookup the IPv6 DA in the mapping table
S06. Update the IPv6 DA with the new mapped SID
S07. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
Notes:
The SIDs in the SRH are not modified.
6.3. End.M.GTP6.D
The "Endpoint behavior with IPv6/GTP decapsulation into SR policy"
behavior (End.M.GTP6.D for short) is used in interworking scenario
for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any
SID instance of this behavior is associated with an SR Policy B and
an IPv6 Source Address A.
Matsushima, et al. Expires January 24, 2022 [Page 20]
Internet-Draft SRv6 Mobile User-Plane July 2021
When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D SID, N does:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP6.D SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy the GTP TEID to buffer memory
S03. Pop the IPv6, UDP, and GTP Headers
S04. Push a new IPv6 header with its own SRH containing B
S05. Set the outer IPv6 SA to A
S06. Set the outer IPv6 DA to the first SID of B
S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields
S08. Write in the last SID of the SRH the Args.Mob.Session
based on the information of buffer memory
S09. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S10. } Else {
S11. Process as per [RFC8986] Section 4.1.1
S12. }
Notes:
The NH is set based on the SID parameter. There is one instantiation
of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already
known in advance. For the IPv4v6 PDU Session Type, in addition we
inspect the first nibble of the PDU to know the NH value.
The prefix of last segment (S3 in above example) SHOULD be followed
by an Arg.Mob.Session argument space which is used to provide the
session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway.
Matsushima, et al. Expires January 24, 2022 [Page 21]
Internet-Draft SRv6 Mobile User-Plane July 2021
6.4. End.M.GTP6.D.Di
The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for
Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6
drop-in interworking scenario described in Section 5.4. The
difference between End.M.GTP6.D as another variant of IPv6/GTP
decapsulation function is that the original IPv6 DA of GTP packet is
preserved as the last SID in SRH.
Any SID instance of this behavior is associated with an SR Policy B
and an IPv6 Source Address A.
When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D.Di SID, N does:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP6.Di SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy S to buffer memory
S03. Pop the IPv6, UDP, and GTP Headers
S04. Push a new IPv6 header with its own SRH containing B
S05. Set the outer IPv6 SA to A
S06. Set the outer IPv6 DA to the first SID of B
S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields
S08. Write S to the SRH
S09. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S10. } Else {
S11. Process as per [RFC8986] Section 4.1.1
S12. }
Notes:
The NH is set based on the SID parameter. There is one instantiation
of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already
Matsushima, et al. Expires January 24, 2022 [Page 22]
Internet-Draft SRv6 Mobile User-Plane July 2021
known in advance. For the IPv4v6 PDU Session Type, in addition we
inspect the first nibble of the PDU to know the NH value.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway.
6.5. End.M.GTP6.E
The "Endpoint behavior with encapsulation for IPv6/GTP tunnel"
behavior (End.M.GTP6.E for short) is used in interworking scenario
for the downlink toward the legacy gNB using IPv6/GTP.
The prefix of End.M.GTP6.E SID MUST be followed by the
Arg.Mob.Session argument space which is used to provide the session
identifiers.
When the SR Gateway node N receives a packet destined to S, and S is
a local End.M.GTP6.E SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 1) {
S03. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP6.E SID, N does:
S01. Copy SRH[0] and S to buffer memory
S02. Pop the IPv6 header and all its extension headers
S03. Push a new IPv6 header with a UDP/GTP Header
S04. Set the outer IPv6 SA to A
S05. Set the outer IPv6 DA from buffer memory
S06. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields
S07. Set the GTP TEID (from buffer memory)
S08. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S09. }
Notes:
An End.M.GTP6.E SID MUST always be the penultimate SID.
The TEID is extracted from the argument space of the current SID.
Matsushima, et al. Expires January 24, 2022 [Page 23]
Internet-Draft SRv6 Mobile User-Plane July 2021
The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
SR gateway.
6.6. End.M.GTP4.E
The "Endpoint behavior with encapsulation for IPv4/GTP tunnel"
behavior (End.M.GTP4.E for short) is used in the downlink when doing
interworking with legacy gNB using IPv4/GTP.
When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP4.E SID, N does:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP4.E SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Sotre the IPv6 DA and SA in buffer memory
S03. Pop the IPv6 header and all its extension headers
S04. Push a new IPv4 header with a UDP/GTP Header
S05. Set the outer IPv4 SA and DA (from buffer memory)
S06. Set the outer Total Length, DSCP, Time To Live, and
Next-Header fields
S07. Set the GTP TEID (from buffer memory)
S08. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S09. } Else {
S10. Process as per [NET-PGM] Section 4.1.1
S11. }
Notes:
The End.M.GTP4.E SID in S has the following format:
Matsushima, et al. Expires January 24, 2022 [Page 24]
Internet-Draft SRv6 Mobile User-Plane July 2021
0 127
+-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
End.M.GTP4.E SID Encoding
The IPv6 Source Address has the following format:
0 127
+----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
128-a-b a b
IPv6 SA Encoding for End.M.GTP4.E
6.7. H.M.GTP4.D
The "SR Policy Headend with tunnel decapsulation and map to an SRv6
policy" behavior (H.M.GTP4.D for short) is used in the direction from
legacy IPv4 user-plane to SRv6 user-plane network.
When the SR Gateway node N receives a packet destined to a IW-
IPv4-Prefix, N does:
S01. IF Payload == UDP/GTP THEN
S02. Pop the outer IPv4 header and UDP/GTP headers
S03. Copy IPv4 DA, TEID to form SID B
S04. Copy IPv4 SA to form IPv6 SA B'
S05. Encapsulate the packet into a new IPv6 header ;;Ref1
S06. Set the IPv6 DA = B
S07. Forward along the shortest path to B
S08. ELSE
S09. Drop the packet
Ref1: The NH value is identified by inspecting the first nibble of
the inner payload.
The SID B has the following format:
Matsushima, et al. Expires January 24, 2022 [Page 25]
Internet-Draft SRv6 Mobile User-Plane July 2021
0 127
+-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
H.M.GTP4.D SID Encoding
The SID B MAY be an SRv6 Binding SID instantiated at the first UPF
(U1) to bind an SR policy [I-D.ietf-spring-segment-routing-policy].
The prefix of B' SHOULD be an End.M.GTP4.E SID with its format
instantiated at an SR gateway with the IPv4 SA of the receiving
packet.
6.8. End.Limit: Rate Limiting behavior
The mobile user-plane requires a rate-limit feature. For this
purpose, we define a new behavior "End.Limit". The "End.Limit"
behavior encodes in its arguments the rate limiting parameter that
should be applied to this packet. Multiple flows of packets should
have the same group identifier in the SID when those flows are in the
same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of
the rate limit segment SID is as follows:
+----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+
128-i-j i j
End.Limit: Rate limiting behavior argument format
If the limit-rate bits are set to zero, the node should not do rate
limiting unless static configuration or control-plane sets the limit
rate associated to the SID.
7. SRv6 supported 3GPP PDU session types
The 3GPP [TS.23501] defines the following PDU session types:
o IPv4
o IPv6
o IPv4v6
o Ethernet
o Unstructured
Matsushima, et al. Expires January 24, 2022 [Page 26]
Internet-Draft SRv6 Mobile User-Plane July 2021
SRv6 supports the 3GPP PDU session types without any protocol
overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4
for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU
sessions).
8. Network Slicing Considerations
A mobile network may be required to implement "network slices", which
logically separate network resources. User-plane behaviors
represented as SRv6 segments would be part of a slice.
[I-D.ietf-spring-segment-routing-policy] describes a solution to
build basic network slices with SR. Depending on the requirements,
these slices can be further refined by adopting the mechanisms from:
o IGP Flex-Algo [I-D.ietf-lsr-flex-algo]
o Inter-Domain policies
[I-D.ietf-spring-segment-routing-central-epe]
Furthermore, these can be combined with ODN/AS (On Demand Nexthop/
Automated Steering) [I-D.ietf-spring-segment-routing-policy] for
automated slice provisioning and traffic steering.
Further details on how these tools can be used to create end to end
network slices are documented in
[I-D.ali-spring-network-slicing-building-blocks].
9. Control Plane Considerations
This document focuses on user-plane behavior and its independence
from the control plane. While there are benefits in an enhanced
control plane (e.g., to dynamically configure SR policies from a
controller), this document does not impose any change to the existant
mobility control plane.
Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for
the new behaviors defined in this document.
10. Security Considerations
The security considerations for Segment Routing are discussed in
[RFC8402]. More specifically for SRv6 the security considerations
and the mechanisms for securing an SR domain are discussed in
[RFC8754]. Together, they describe the required security mechanisms
that allow establishment of an SR domain of trust to operate
SRv6-based services for internal traffic while preventing any
Matsushima, et al. Expires January 24, 2022 [Page 27]
Internet-Draft SRv6 Mobile User-Plane July 2021
external traffic from accessing or exploiting the SRv6-based
services.
The technology described in this document is applied to a mobile
network that is within the SR Domain.
This document introduces new SRv6 Endpoint Behaviors. Those
behaviors do not need any special security consideration given that
it is deployed within that SR Domain.
11. IANA Considerations
The following values have been allocated within the "SRv6 Endpoint
Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment
Routing Parameters" registry:
+-------+--------+-------------------+-----------+
| Value | Hex | Endpoint behavior | Reference |
+-------+--------+-------------------+-----------+
| 40 | 0x0028 | End.MAP | [This.ID] |
| 41 | 0x0029 | End.Limit | [This.ID] |
| 69 | 0x0045 | End.M.GTP6.D | [This.ID] |
| 70 | 0x0046 | End.M.GTP6.Di | [This.ID] |
| 71 | 0x0047 | End.M.GTP6.E | [This.ID] |
| 72 | 0x0048 | End.M.GTP4.E | [This.ID] |
+-------+--------+-------------------+-----------+
Table 1: SRv6 Mobile User-plane Endpoint Behavior Types
12. Acknowledgements
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.
13. Contributors
Kentaro Ebisawa
Toyota Motor Corporation
Japan
Email: [email protected]
Tetsuya Murakami
Arrcus, Inc.
United States of America
Matsushima, et al. Expires January 24, 2022 [Page 28]
Internet-Draft SRv6 Mobile User-Plane July 2021
Email: [email protected]
14. References
14.1. Normative References
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-13 (work in progress),
May 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[TS.23501]
3GPP, "System Architecture for the 5G System", 3GPP TS
23.501 15.0.0, November 2017.
14.2. Informative References
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network",
draft-ali-spring-network-slicing-building-blocks-04 (work
in progress), February 2021.
Matsushima, et al. Expires January 24, 2022 [Page 29]
Internet-Draft SRv6 Mobile User-Plane July 2021
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S.,
Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use-
Cases", draft-camarilloelmalky-springdmm-srv6-mob-
usecases-02 (work in progress), August 2019.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-17 (work in progress), July 2021.
[I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
draft-ietf-spring-sr-service-programming-04 (work in
progress), March 2021.
[I-D.matsushima-spring-srv6-deployment-status]
Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K.
Rajaraman, "SRv6 Implementation and Deployment Status",
draft-matsushima-spring-srv6-deployment-status-11 (work in
progress), February 2021.
[TS.29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017.
[TS.38415]
3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations
This document introduces new SRv6 Endpoint Behaviors. These
behaviors have an open-source P4 implementation available in
<https://github.com/ebiken/p4srv6>.
Additionally, a full implementation of this document is available in
Linux Foundation FD.io VPP project since release 20.05. More
Matsushima, et al. Expires January 24, 2022 [Page 30]
Internet-Draft SRv6 Mobile User-Plane July 2021
information available here: <https://docs.fd.io/vpp/20.05/d7/d3c/
srv6_mobile_plugin_doc.html>.
There are also experimental implementations in M-CORD NGIC and Open
Air Interface (OAI).
Authors' Addresses
Satoru Matsushima (editor)
SoftBank
Japan
Email: [email protected]
Clarence Filsfils
Cisco Systems, Inc.
Belgium
Email: [email protected]
Miya Kohno
Cisco Systems, Inc.
Japan
Email: [email protected]
Pablo Camarillo Garvia (editor)
Cisco Systems, Inc.
Spain
Email: [email protected]
Daniel Voyer
Bell Canada
Canada
Email: [email protected]
Matsushima, et al. Expires January 24, 2022 [Page 31]
Internet-Draft SRv6 Mobile User-Plane July 2021
Charles E. Perkins
Lupin Lodge
20600 Aldercroft Heights Rd.
Los Gatos, CA 95033
USA
Email: [email protected]
Matsushima, et al. Expires January 24, 2022 [Page 32]
Diff_ draft-ietf-dmm-srv6-mobile-uplane-13.txt - draft-ietf-dmm-srv6-mobile-uplane.txt.html
(text/html, 103.2 KB) - not displayed