Hi Jeffrey, Inline with PC. New version of the draft posted (rev17).
Thanks, Pablo. -----Original Message----- From: Jeffrey (Zhaohui) Zhang <[email protected]> Sent: viernes, 27 de agosto de 2021 1:01 To: Pablo Camarillo (pcamaril) <[email protected]> Cc: [email protected] Subject: Additional draft-ietf-dmm-srv6-mobile-uplane-16 comments 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. [PC] "Management" removed. 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? [PC] s/shows/specifies 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. [PC] Feel free to propose a different text. In the traditional and enhanced mode the SRv6 endpoints are the mobility user-plane anchors. 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/ [PC] Changed. 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"? [PC] Yes... in the same way today they need to have the GTP-U tunnel parameters installed in the forwarding plane. Not sure I get your point. 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? [PC] Added. Our example topology is shown in Figure 2. In traditional mode the gNB and the UPFs are SR-aware. Strike "In traditional mode"? [PC] Removed. 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". [PC] Reverted the order of those two last sentences which I believe improves readability. 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? [PC] As stated in the draft "U1::1 represents an anchoring SID specific for that session at UPF1." [PC] and actually I would expect all the addressing of this document to be changed to 2001::db8:: as it goes through IESG... 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"? [PC] Done. 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. [PC] Based on your previous feedback we already added in rev16 the last paragraph of 5.2.2. 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. [PC] The value of the SRv6 Service SID assigned does not need to include the TEID. Hence using gNB::TEID seems incorrect to me. Instead one particular SID is associated with the service. The last paragraph highlights exactly that. 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. [PC] The draft currently allows both options. Its an operational choice from the operator to select one. I have a personal preference over Args.Mob.Session, but an operator might prefer the other option hence keeping both options available. 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). [PC] SRv6 identifies services by using a different SID. In both cases, different UPF or gNB addresses are needed to determine the table. [PC] Same as with any SRv6 solution -not specific to SRv6 mobile- no? I don't see the difference with respect to RFC8986. 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? [PC] The content is still an IPv6 address. The IPv6 address is different depending on the required SLA (as stated in the text). * 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? [PC] There is no state at all. All the information is contained in the packet. If so, uplink does not seem to need per-PDU session state either? [PC] In the uplink you need to store the entire SR policy that will be used. Therefore, there is more state in uplink that in the downlink. This is further explained in 5.3.1.3. I agree there is no per-PDU session state, it is less than that. 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"? [PC] Removed "located in the IPv6 DA" from the sentence. 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. [PC] Same reply as before. 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. [PC] If sharing is not used, then you need one policy for each different PDU session (in order to be able to map it to a different SLA). 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. [PC] Out of the scope of this draft as stated in the draft. I don't see why this section deserves special treatment from the rest of the doc. 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). [PC] s/remote steering capabilities provided by SRv6/remote steering capabilities provided by the Segment Routing BSID./ [PC] I've changed the IPv4 sentence to: " In IPv4 this construct is not available, and building a similar mechanism would require a significant address consumption." 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? [PC] CLI, Netconf, or other means. 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). [PC] The SA is provided in the dataplane by using the encoding seen in Figure 10. 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? [PC] We are already doing that today (classification based on TEID). Compared to using per-SLA/tenant IPv4 addresses, which is more practical? [PC] Then you have the address consumption issue... 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. [PC] It is a mirror... 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). [PC] I agree with you that would be a good enhancement, however I believe this cannot be done. The usage of Args.Mob.Session requires allocating a userplane identifier. I don't think in Traditional mode we can have any user plane identifier different from TEID. 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. [PC] Corrected indeed. 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. [PC] Ill remove the line as that goes really into implementation specific on whether you the mapping in a single shot or your need the extra 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. [PC] Added. 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? [PC] Added in S02. 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). [PC] Agreed. Sentence removed. 6.4. End.M.GTP6.D.Di As mentioned in the other email, this is not needed? [PC] The WG decided to add the DropIn mode as it found value after the demos shown by Arashmid. [PC] If the working group wants to change that, fine with me. However, given that this is just one SRv6 Endpoint Behavior.. I don't see the problem in keeping it defined in the document. 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. [PC] Indeed. Changed. 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: [PC] The IPv6 Source Address also encodes the IPv4 address that has to be used in the crafted GTP-U packet. See figure 10. 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? [PC] Sentence removed. This is not a requirement (as discussed earlier). 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. [PC] This SID is added when the operator wishes to Rate Limit a particular flow of packets. The SID contains two arguments (group-id and limit-rate). [PC] The node instantiating this segment has a rate limiting policy that is applied to the packet. 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. [PC] Added. 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. [PC] The payload of the packet is neither inspected nor modified. Hence if you wish to use encryption on the packet payload there should be no problem. Please detail more if you think otherwise. I might be missing your point. Jeffrey _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
