(+ Charlie)
From: dmm <[email protected]> on behalf of "Pablo Camarillo (pcamaril)"
<[email protected]>
Date: Monday, 26 February 2018 at 21:05
To: "[email protected]" <[email protected]>
Cc: "Voyer, Daniel" <[email protected]>, "cf(mailer list)" <[email protected]>,
"Miya Kohno (mkohno)" <[email protected]>, "[email protected]"
<[email protected]>
Subject: [DMM] SRv6 for Mobile User-Plane
Hello authors, DMM,
I have reviewed your I-D on SRv6 for mobile user-plane and I would like to make
some proposals. I have already discussed and brainstormed the details with some
of the authors of the draft and they agree to this changes, however I would
like to get the WG feedback on it.
Thank you,
Pablo.
I believe its straightforward to support IPv4 UE traffic by doing SRv6 with
T.Encaps behavior. Hence, I think this should be documented in the draft.
The encapsulation behavior should be the default one, both for IPv4 and IPv6 UE
traffic. However, a specific provider is allowed to do SRH insertion within a
controlled domain [draft-voyer-6man-extension-header-insertion-02] for UE IPv6
traffic.
Also, in order to reduce overhead at the UPFs when using encapsulation, I would
replace the End.B6 function for a new End.MAP function.
For example, if we consider the following topology:
UE----gNB----UPF1----UPF2
Then the uplink packet flow for the basic mode would look like this:
UE_out: (A, Z)
gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps <U1::1>
UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP
UPF2_out: (A, Z) -> End.DT
The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.
Notice that using encapsulation, if you compare it with today user-plane using
IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 header),
while GTP over IPv6 is using 56B (IPv6, UDP, GTP).
=======
With respect to the aggregation mode, aside from using the encapsulation mode
as described before, I would also like to add a note on the I-D on the fact
that we can support the aggregation mode without changes in the N2 interface:
The current I-D for aggregation mode assumes that the gNB (uplink) has
knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and
so on. Even though the I-D does not describe how the gNB is retrieving this
information, I would like to make a statement on the fact that there are two
alternatives:
A. The N2 interface is modified in order to signal a SID list to the gNB.
B. The N2 interface is not modified. In this case, we signal through the N2
interface an SRv6 BindingSID, that the gNB is going to resolve into a SID list
via an SDN controller either using PCEP, reverse DNS lookup or LISP.
I’m aware that the I-D focuses on the user-plane, however I believe it’s
important to state this alternatives since it simplifies the adoption and
reduces impact in the existing mobile architectures (without going into the
details on the mechanisms for each one of the alternatives of LISP, PCEP,
reverse DNS-lookup).
=======
On the other hand, the current I-D proposes a mechanism for stateless
interworking with legacy access networks that doesn’t support SRv6 (SGW and/or
eNB). This mechanism presented in the I-D is limited to IPv4/GTP legacy
networks. I would like to propose a mechanism to support interworking with
legacy gNBs that does not support SRv6 but do support IPv6/GTP.
The main benefit comes from the fact that we can leverage an SRv6 BindingSID to
have remote classification and steering of the UE traffic over an SR policy
[draft-filsfils-spring-segment-routing-policy].
In this scenario, I propose that we add the notion of an SR GW -as the current
stateless interworking node in the I-D-. This SR GW can be either a software
based platform -e.g. VPP- or any existing router -the mechanism is simple and
can be supported in existing HW-. This SR GW receives through the control plane
the SR policies and installs the required Binding SIDs.
Then, for any UE connecting to a gNB, the N2 interface is going to signal an
IPv6 address and a TEID. However, the difference is that with this new
mechanism the IPv6 address that we are going to signal is going to be an SRv6
BindingSID instantiated at the SR GW.
The overall workflow is the following:
Uplink
Note: S1, S2 represent service functions and C1 represents a node for TE
purposes
UE sends its packet (A, Z) on a specific wireless bearer to its gNB
gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID T
(N2 interface unchanged)
gNB_out: (gNB, B) (GTP: TEID T) (A, Z) ;; Interface N3 is
unchanged
SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z) ;; new End.GTP.UP
S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)
C1_out: (SRGW, U2::1) (A, Z) ;; assuming
PSP
UPF2_out: (A, Z) ;;
End.DT
Downlink
UPF2_in: (Z, A)
;; UPF2 maps the flow with SID list <C1, S1, SRGW::TEID, gNB>
UPF2_out: (U2::1, C1) (gNB, SRGW::TEID, S1, SL=3) (Z, A) ;; T.Encaps
C1_out: (U2::1, S1) (gNB, SRGW::T, S1, SL=2) (Z, A)
S1_out: (U2::1, SRGW::TEID) (gNB, SRGW::T, S1, SL=1) (Z, A)
SR_GW: (SRGW, gNB)(GTP: TEID=T)(Z, A) ;; End.GTP.DN
gNB_out: (Z, A)
The key points are:
- gNB is unchanged and encaps into GTP (N3 interface is not modified). gNB only
needs to support IPv6 which is currently common in existing deployments.
- 5G Control-Plane (N2 interface) is unchanged: 1! IPv6 address (i.e. a BSID at
the SR GW)
- SR GW removes GTP, finds SID list related to IPv6 DA (BSID), add SRH with SID
list
- Same TE, NFV and scale properties as Aggregation mode
- There is NO state for the downlink at the SR gateway
- There is simple state in the uplink at the SR gateway (notice that since we
are leveraging the aggregation mode, we expect few SR policies on this node. SR
policies are shared across UEs)
- As soon as the packet leaves the gNB (uplink), the traffic is SR-routed. This
simplifies considerably network slicing. [draft-hegdeppsenak-isis-sr-flex-algo].
- Traffic is already classified and steered into an SR policy when it arrives
to the SR GW.
Finally, I believe that this mechanism is so simple, that it would be trivial
to implement it in VPP [https://wiki.fd.io/view/VPP/What_is_VPP%3F] . Hence if
the working group believes that this is interesting work and we add it to the
I-D, I will analyse how to implement it in this platform.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
