[DMM] Additional draft-ietf-dmm-srv6-mobile-uplane-16 comments

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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