Hi Pablo,
Some editorial/nit comments and some more substantial questions/comments below.
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.
A nit question - why "management" systems? That sounds like user plane is not
involved.
This document shows the applicability of SRv6 (Segment Routing IPv6)
to mobile networks.
This document is not just "showing" the applicability. It actually specifies
how it is done, right?
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.
The last sentence is not exactly true. The SRv6 endpoint nodes could be GWs.
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.
s/purposes/purposes transparent to 3GPP functionalities/
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
associated with each PDU Session, and the SID list only contains a
single SID.
Does "a unique SRv6 SID associated with each PDU Session" mean that gNB/UPF
will have those individual unique SIDs installed in the forwarding plane"?
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.
Also QFI?
Our example topology is shown in Figure 2. In traditional mode the
gNB and the UPFs are SR-aware.
Strike "In traditional mode"?
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).
The last sentence is misleading. SID U1::1 is constructed by gNB and it should
really be U1::TEID where U1 is the "single IPv6 address is provided to the gNB".
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).
U::1 should be U1::TEID1, and U2::1 should be U2::TEID2?
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.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the
gNB and the UPF are SR-aware.
Strike "In the Enhanced mode"?
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>.
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).
As we have discussed before, you either need to use U1::TEID so that UPF1 can
use the TEID to determine in which table to do End.DT2/4/6, or you need to
point out that different U1 addresses need to be used for different tables.
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::1, S1; SL=2)(Z,A)->H.Encaps.Red
C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A)
S1_out : (U1::1, gNB::1)(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 towards the UE. The SID gNB::1
is one example of a SID associated to this service.
Same as above. gNB::1 in the last sentence above is not enough - gNB::TEID
needs to be used to do End.DX2/4/6.
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 option is to use the Args.Mob.Session
(Section 6.1). Another option comprises the gNB performing an IP
lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2
behaviors.
To clarify, when I say gNB::TEID, I do refer to use of Args.Mob.Session. I
don't think we should be shy from calling out gNB::TEID.
If you want to do End.DT2/4/6 on gNB, the following should be pointed out:
- this is a change of gNB behavior
- we still need a way to identify in which table to do it - and like in the
uplink case, you either use TEID or use different gNB addresses.
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).
The scalability improvement comes when you don't need to use TEID for the
following:
- for uplink, determining the table in which to do End.DT2/4/6
- End.DX2/4/6 for downlink (End.DT2/4/6 will be used).
In both cases, different UPF or gNB addresses are needed to determine the table.
That should be clarified, including how the addresses are determined.
5.3.1. Interworking with IPv6 GTP
* The 5G Control-Plane towards the gNB (N2 interface) is unmodified;
one IPv6 address is needed per SLA(i.e. a BSID at the SRGW). The
SRv6 SID is different depending on the required SLA.
Is it that the N2 signaling *encoding* is not changed, but *content* is indeed
changed so that different IPv6 addresses can be given for different SLA/tenant?
* There is no state for the downlink at the SRGW.
* 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.
I am still having trouble grasping the "no state for downlink" and "simple
state for uplink" difference.
For downlink, there is End.M.GTP6.E, right? What are you referring to when you
say "no state for downlink"? Do you mean no per-PDU session state?
If so, uplink does not seem to need per-PDU session state either? Even in the
"traditional mode", all you need is one End.M.GTP6.D SID that put together
U::TEID.
If you aggregate (so that UPF does not need to look at TEIDs), how does the
SRGW know what SLA/tenant a PDU session is associated with? A gNB/UPF knows
that because of N2/N4 signaling, but SRGW is not involved in N2/N4 signaling.
If it relies on different IPv6 addresses, then it seems that "traditional mode"
actually has few state than the enhanced mode?
* In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic
into an SR policy when it arrives at the SRGW.
"SRv6 BSID located in the IPv6 DA" does not read well. Do you mean "... on the
SRGW"?
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
End.M.GTP6.D does the following:
S02. Copy the GTP TEID to buffer memory
...
S08. Write in the last SID of the SRH the Args.Mob.Session
based on the information of buffer memory
Therefore, U2::1 really should be changed to U2::TEID.
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.
As commented above, the sharing/aggregation is based on different addresses for
different SLA/tenants signaled over N2. If sharing/aggregation is not used
(i.e. traditional mode), there is no need for per-session state for uplink
either.
5.3.2. Interworking with IPv4 GTP
In this interworking mode the gNB uses GTP over IPv4 in the N3
Interface
What does SMF tell UPF over N4? GTP with IPv4 parameters? Good to clarify.
5.3.2.1. Packet flow - Uplink
...
Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP
differs. This is due to the fact that in IPv6/GTP we can leverage
the remote steering capabilities provided by SRv6. In IPv4 this is
not the case, and it would require a significant address consumption.
"remote steering capabilities provided by SRv6" is unclear about its meaning -
perhaps just remove the sentence and simply talk about address consumption.
Different addresses are used for different SLAs/tenants - if that's not a
concern even for IPv4 then it be can use for IPv4 as well and otherwise either
per-session classification is needed on the SRGW or just don't do aggregation
at all for IPv4 (then you just need one IPv4 route to come up with the U::TEID
SID in the outgoing packets).
On the other hand, how are the classification rules configured on the SRGW
since it is not involved in the N2 signaling? Is it feasible at all to
configure those on the SRGW?
5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows:
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)
...
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.
What is the SA? Is it an address on the UPF or is it a local address on the GW?
If it is of the GW, is there a need to carry it in the SRH?
If it is of the UPF while the packet really originated at the GW, why couldn't
same be done for IPv6 (in 5.3.1.1, when SRGW sends out packets it uses its own
not the gNB address as source).
5.3.2.3. Scalability
...
For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis according to a classification engine. There is
state for steering the different sessions in the form of an SR
Policy. However, SR policies are shared among several UE/sessions.
Is it really feasible to have those per UE/session classification rules?
Compared to using per-SLA/tenant IPv4 addresses, which is more practical?
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.
5.3 talks about interworking between an SRv6 UPF and GTP gNB. 5.4 talks about
using SRv6 to connect GTP gNB and GTP UPF. Perhaps it's better to talk about
interworking between SRv6 gNB and GTP UPF first, and then if you put two
interworking mode together you achieve what current 5.4 achieves - a GW
basically presents a GTP NF as an SRv6 NF.
In fact, GW for UPF just seems to be a mirror of the GW for gNB.
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.
In the other email I talked about not needing End.M.GTP6.D.Di.
6.1. Args.Mob.Session
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.
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 draft. [I-D.murakami-dmm-user-plane-message-encoding] defines
one possible encoding.
I actually missed that Args.Mob.Session was encoding information like QFI
(that's why I wanted to have a normative reference to draft-murakami).
Why don't we use it for traditional, non-aggregate mode as well (the above text
only says it's required for aggregation)? In that mode different SIDs are used
for different sessions, but those SIDs can still be viewed as a locator+
Args.Mob.Session (which also encodes QFI that is also needed).
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.
Hmm ... not sure about the last sentence. It seems that End.MAP is used for
intermediate UPFs instead of anchoring UPFs.
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.
Since the entire IPv6 DA is the End.MAP SID, e.g. per the following in 5.1.2:
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.
The SID itself can do the mapping already w/o looking up a mapping table, so
S05 is not needed, right? In other words, the mapped to SID is associated with
this SID already, no need to do a lookup.
The above procedures would make sense only if just part of the IPv6 address
(e.g. the U1 part) is the SID, while the ::2 part is used to lookup a mapping
table.
6.3. End.M.GTP6.D
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
Add "(NH)" after "Next-Header" above? There were several "NH" references later.
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. }
Shouldn't we copy the QFI part as well in step S08?
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway.
Why is the above required? A is the source address of the packet output by the
GW. It's understandable that on reverse direction, A could be an End.M.GTP6.E
SID but that is not mandatory - a different address could be used (either the
gNB address as I suggested or another local address on the GW).
6.4. End.M.GTP6.D.Di
As mentioned in the other email, this is not needed?
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.
This is used for uplink in drop-in mode as well.
6.6. End.M.GTP4.E
S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Sotre the IPv6 DA and SA in buffer memory
What is SA used for? The DA part provides all the information according to
5.3.2.2, which seems to be conflicting from the following:
Notes: The End.M.GTP4.E SID in S has the following format:
0 127
+-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
Figure 9: 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
Figure 10: IPv6 SA Encoding for End.M.GTP4.E
6.7. H.M.GTP4.D
Similarly, the example in 5.3.2.1 should be modified to match this.
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.
Similarly, why is the above required?
6.8. End.Limit: Rate Limiting behavior
Can you elaborate how this is used? An example of inserting this SID into one
of the SRHs will be helpful.
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.
It should be pointed out that for aggregation, N2/N4 need to give out different
NF addresses for different SLA/tenants.
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
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.
For interworking, GTP and SRv6 packets are converted to each other. Does that
mean encryption can not be used? That should be pointed out.
Jeffrey
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
