Dmm Status PagesDistributed Mobility Management (Active WG)
Int Area: Éric Vyncke, Suresh Krishnan | 2012-Jan-10 —Chairs:
IETF-105 dmm minutes
Session 2019-07-24 1000-1200: Notre Dame - dmm chatroom
Note: David I Allan & John Kaippallimalil Title: Administrivia & Intro, WG organization & milestones Description: Agenda, Note-taker negotiation and WG Progress Update Presenters: Chairs new co-chair - Satoru Matsushima Scribe: Dave Allan FPC document split discussions due to the size of the document, hard to get reviewers Suresh: Reviewer pool for each is different. Can look for YANG best practices separately.Not everyone needs to read the YANG module. Three independent steps. Document adopted procedurally as it was a split of an adopted document simply to facilitate progress. Sri: Those familiar with YANG semantics can look that over. FPC needs to be republished. 3 other documents passed WG last call. Suresh: Want to get these docs off my queue in the next two weeks. On demand mobility needs some discussions resolved, Way forward not clear. Not too much WG action required. Hope to resolve by Friday. 2. Topic Name: SRv6 Mobile Userplane Presenter: Satoru Matsushima Draft reference: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane Summary of updates 04 to 05 Stateless mapping rule update. Pseudo code updates for mappings Hackathon Feedback - all GTP-U IWF implemented in FD.io VPP - New end function to support drop in scenario not in the document. SRv6 transiting to GTP-U. In the middle of the path the SRV6 plane can be manipulated due to operator policy. Suresh: What is the use case for drop in? A: To map into N6 interface. When function is in the DN. And routing differentiation based on SID instead of GTP-U end point. Suresh: But you are just popping IP out into N6. Second use case is roaming. AD hat off it seems reasonable. Mailing list comments: - can we add drop in mode as described at IETF 103 (GTP/SRv6/GTP translation) - Does the draft need to describe it. Sri: Chair hat off, it would be better to describe it. - when is it required to use args.mob.session - Helps when sessions aggregated on a SID - doc should elaborate more on arg.mob.session use cases. - Add some text, specific sentence proposed - how does SRGW learn SID list to a DA, does it need to be per session - modify text in 6.3 to indicate SID can be shared - use of term "anchor" not clear in the document - resolution TBD Sri: anchor is a routing end point (UE IP address is topologically configured) · Arashmid: they are all UPF's. Changing the term might solve the problem. · Sri: UPF is not an IETF term. · Arashmid: Do not want to find every UPF and use case. · Suresh: Use 3GPP as examples, not definitions to avoid overloading what we are saying. · Marco Liebsh: We could use DPN DPA, data plane node/anchor and go around this. · Uma: We do not have to redefine 3GPP stuff. Lots of stuff LI etc. happens at a UPF. · - what about translating GTP PING? · - cover GTP messages in a separate document (e.g. end marker) · Comments effectively rejected · - what is specific table · - keep current text · - comment on downling 5.1.2 · - keep current text · - 5.2 what about SID overhead and header compression · - keep current text · Sri: Is this specfic to this work item or SRv6 in general... Neither(?) · - · - 18.104.22.168 downlink IW with IPv6 GTP · - N4 signalling is one solution --> keep current text · - 22.214.171.124 · - 6.2 end.map · - how to populate mapping table is out of scope · - 6.2 segment list is SIDs, text to be added to clarify · · Have VPP and P4 code implementations. Looking for other implementations. · · ready for WGLC after comments resolved. · 3. Topic Name: Transport Network Aware Mobility for 5G Presenter Name: John Kaippallimalil, Uma Chunduri Draft Reference: draft-clt-dmm-tn-aware-mobility-04 Problem no clear or standard mapping function between SSTs (eMBB, URLLC, MIOT) and underlay transport. QoS characteristics need to be preserved across mobility events. Objectives: framework to apply other IETF technologies, how to use PPR, provide a mapping function, and a reference arch. Non--objectives: replacing GTP Sri: Was this presented in 3GPP. Uma: No, CT4 delegate had significant changes, but this is IETF work. Dave: Can you elabrate on provide a clear mapping - an API? Uma: what needs to be done to be mapped to an underlying tunnel (adaptation) An Nguyen: Will this touch the MPLS layer. · Uma: IETF has lots of TE technologies, we do not want to touch anything there. Want to show PPR specifically and a framework. An: How does QCI mapping and DSCP play into this. Uma: UDP source based mapping to SR tunnels is one way. In 5G there is a QFI field in the GTP header. An: Would you coordinate this with 3GPP folks? Uma: At some point yes. An: Would be good to get coordination people involved. Suresh: We need to sort next steps if this is targeted to 3GPP. How do we communicate this exists and does it meet their needs? I think other work besides CT4 is needed so a liaison or similar. We had a coordination meeting on Monday. Idea is that this goes on a dependency list. That is independent of what happens in IETF, but if you want something to happen in 3GPP you need to do this. John: In 3GPP there are multiple groups we need to consider, SA5, SA2 architecture does not think anything is needed at this point. Suresh: I can ship it off to a wide distribution list. John: Trying to minimize overlap to ensure it is clear this is IETF work. Uma: They need to know about it as it relates to their technology. Suresh: Best to share status early, 3 month hysterysis. Changes to 04 - ch 2.2 mapping between 5G and transport slices. - revision of integrated approach in ch 2.1, and PPR ch 3 - introduces MTNC - mobile transport network context - maps 5QI to transport slice instance MTNC is carried in IP packet header extensions This as presented in TEAS. Uma: one problem with version 3 was we tried not to change the GTP packet. Mapping QFI was difficult due to the depth you had to look in the packet. John: Can provide a mapping downstream. Eric Klein: So the packet is GTP, and you are further reducing the MTU by 12 bytes? A: Yes. Satoryu: One idea in bits and bytes to carry the MTNC. You mentioned SRv6 could be a transport. The SID could indicate this. A: Agree. If I understood you correctly. Uma: One request for the WG is if there is another approach that does not require packet modification, or looking deep into GTP extension headers. Eric: The destination is gNodeB to UPF? John: Can be gnodeB or UPF. Eric: Can these things have entire /64s to themselves. Put the ID in the lower part of the address? Uma: Great ID. Eric: Is this public network, for v6 you can do this, for v4 use 12 extra bytes. Satoryu: If not touching the existing architecture and needs to be a more generic solution. Touching some sort of VPN solution, and WG. John: I can work with you on this. Looking for comments and suggestions. 4. Topic Name: User Plane Protocol and Architectural Analysis on 3GPP 5G System Presenter Name: Takuya Miyasaka Draft Reference: https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ Background of this draft has not changed. Major updates: - slice type description (4.1) eMBB, uRLLC, MIoT, V2X (Rel 16) - [missed other changes] PFCP State Information on N4 John: N4 and PFCP, are you also considering N2, A: currently no. Supporting URLLC in 23.501- redundant UP paths using dual connectivity (redundant transmission, 2 UPFs/RAN fns, 22 I-UPFs and N3/N9 tunnels) GTP-U sequence number to detect duplicated packets works in simple scenario. I-UPF scenario must transfer the sequence number across GTP tunnels. Sequence number and other options to carry this information under study in 3GPP. 5.Topic Name: YANG for Protocol for Forwarding Policy Configuration (FPC) Presenter Name: Charles Perkins Draft Reference: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-yang/ Charlie unable to attend. 6. Topic Name: Control-/Data Plane for N6 Traffic Steering – Applicability to MEC for automotive use cases Presenter: Marco Liebsch Draft: https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt Automotive use case - may have to move the services closer to the user, and hence the UPF is closer as well. This should be done without unambigous traffic routing between the UPFs of that session. Uses routing policies to accomplish this. N6 PEPs - loose vs tight coupling Considering loose coupling where the policies are independent of mobile core (i.e., not via N4) The draft supports both loose and tight coupling Contributing some of these aspects to ETSI MEC MEC deployment with polcy manager DPN colocated with the UPF. John: If you have a network between AS and UPF are you covering the scenario where it is a nonp-topological route to the UPF. A: If you move any of the end points we deviate from standard routes, and therefore need host routes. This is done by policy controllers. If the car is moving at some point you may make the decision to relocate the edge. We try to leverage the VPN overlay on N6 to keep this procedure as independent of the 5G control plane as possible. Investigating how far we can take this both intra and inter domain. A lot of technology challenges. Whatever we can do to support this on N6 we want to investigate. Employ SR, header rewrite, tunnels. Cross domain handover and edge relocation case. John: You mentioned preloading policy, is predicting the path the solution to sorting out control latency? A: We look at proactive vs. reactive mechanisms. If you can select target beforehand, you can set up resources. One of the last steps in our scenario. We can prepare resources in advance, something we currently look at. Sri: Prediction mechanism? A: we are investigating. Interested in WG adoption, liaising to 3GPP. Sri: Looking for WG feedback, no action beyond that, right? A: Yes. 7. Topic Name: Enterprise IP Mobility - New Requirements Presenter Name: Charles Perkins Draft Reference: None Charlie unable to attend. Meeting closed.