DMM Working Group - IETF 115

Tuesday, 8 November 2022, 09:30-11:30 (UTC)

Chairs: Sri Gundavelli, Dapeng Liu, Satoru Matsushima

Minute taker: John Kaippallimalil

Login to the IETF datatracker to access:

• Meetecho:
  https://meetings.conf.meetecho.com/ietf115/?group=dmm&short=dmm&item=1
• Note: https://notes.ietf.org/notes-ietf-115-dmm
• Zulip: https://zulip.ietf.org/#narrow/stream/dmm

Agenda

• Administrivia & Intro, WG organization & milestones, Chairs, 5 min.

Working Group Drafts

• AD Review update for draft-ietf-dmm-srv6-mobile-uplane, Erik/Sri,
  5min.
• 3GPP input from Lionel (CT4 chair)
• Authors are ok to comply with 3GPP and be consistent
• Suresh clarifies that the architecture may propose improvements but
  will not change 3GPP

• Hannu asks for last call clarification on the draft

• Mobility aware Transport Network Slicing for 5G,
  draft-ietf-dmm-tn-aware-mobility, John Kaippallimalil, 15 min.

how does the 3GPP network relate the 3GPP configuration (GTP-U) to IP
for slices (Tianji)
Hannu clarifies that this is an active discussion in TEAS
Requests for working group and chair reviews of draft

Individual Drafts

• Mobile User Plane Evolution, Zhaofui Zhang, 15min.
  draft-zzhang-dmm-mup-evolution
  distributed UPF and gNB as motivation. Software may run separate
  these functions
  what if we combine in 6G? This is identified in the draft as ANUP
  The rest is routing switching
  DU, CU, UPF may be in the same data center
  Sri asks how does mobility work?
  Response that there is no change to it
  Hannu asks what changes if we integrate these functions now?
  Response that signaling changes (in later slide)
  Suresh asks similar question as Hannu: and adds handover from 1 gNB
  to another where the IP address can change
  Multiple RRU/DU will send to a more central CU. This should be
  stated as an assumption
  Suresh asks about TEID and QoS.
  Author responds that it needs to be addressed
  John asks about QoS model which is one constraint and this does not
  address it
  Author will follow up off line
  Periodic refresh of N3 tunneling and signaling is a cost (GTP-U)
  NAT and overlapping private address space, gateways does not change
  handling
  ULCL/I-UPF for MEC- where filter intercepts some flows. Avoided by
  distributed UPF, and ANUP does not change this.
  Does the AN have to do more work?: the total amount of work is not
  increased.
  Author responds that for capacity planning, it may be easier.
  Does AN complexity increase? The CU already handles significant work
  and resolution of some IP aspects can be reduced.
  Is this against micro service architecture?
  However, this is about integrating forwarding functions and is not
  about micro-services.
  Hannu asks how multi access is supported?
  Author responds and will follow up offline
  Marco likes draft but notes that it is 3GPP specific. What kind of
  changes like traffic steering, etc. are needed in IETF?
  Author responds that no changes are needed in IETF. The aim is to
  get support and feedback from operators and others.
  Satoru asks about fundamental architecture followed by 3GPP groups
  Author agrees that it is a big change
  Lionel comments that 3GPP will consider this as a deployment option,
  the details will be a deployment option. IETF should look for
  IP/user plane optimization (similar comment as Marco)
  Lionel notes that if all the functions are in a box, it does not
  need further standards.
  Author responds that N3 signaling is avoided, but Lionel clarifies
  that implementations can follow anything if 3GPP interfaces
  are not affected (i.e., they are internal implementations inside the
  box)
  Tianji suggest to bring this to 3GPP
  Suresh request to consider all the comments that there are several
  implementations where they combine functions
  The question is how to address cases when the functions are not
  colocated
  Author clarifies that there are simplifications in functions,
  interfaces and will socialize with 3GPP next week.
  Sri requests that IETF aspects need to be identified and then it
  will be relevant to this group.

• SRv6 Mobile User Plane Architecture, Satoru Matsushima, 15min.
  draft-mhkk-dmm-srv6mup-architecture
  Presents updates for this draft.
  Explains collapsed SRv6 MUP PE which is a new model in this version.

  Eric asks if there will be questions about 3GPP architecture and how
  to address?
  Sri clarifies that it is an individual draft at this point.
  Sri asks Eric if IETF can make recommendations as in the same manner
  as IPv6 recommendations were made (if there is consensus)?
  Eric clarifies that if it is informational and one way to do it,
  then maybe.
  Satoru notes that if the operator wants to use an architecture like
  this, the draft provides some guidance. There is no impact to 3GPP
  architecture.
  Suresh says that there may be an impact to 3GPP architecture.
  i.e., for fixed wireless there is a simpler approach with BE traffic
  and no accounting, this may be an approach.
  Whether this impinges arch or not should be discussed here.
  Maybe explore in parallel if 3GPP study or use cases is considered
  in stage 1
  Tianji notes that there may be some impact to 3GPP architecture,
  i.e., 3GPP 5G system may need to get some information/expose to 3rd
  party may need changes. It is not one way but a two way signaling
  impact between user plane (in this draft) and 3GPP CP.
  Author responds that whether the interfaces are exposed are up to
  the implementation.
  Any mobility management system 4G, 5G can use this.

• Cryptographically Generated Device identifiers, Sri Gundavelli,
  15min.
  draft-gundavelli-dmm-device-identifier
  how can multiple devices use the same identity
  semantics for device identification
  solution with cryptographically generated device identifiers
  Lionel asks if using device identifier that is encrypted, how it
  will be used
  Sri answers that key pairs are used and so the network can validate.

  Tianji asks about SUPI allocated by the operator
  Sri notes that SUPI is on the 5G side, but there is question of
  WiFi, i.e., it should be at a layer above
  Lionel notes that it will be IMEI and there is a solution to encrypt

• Media Header Extensions for Wireless Networks, John Kaippallimalil,
  15min.
  draft-kaippallimalil-tsvwg-media-hdr-wireless
  motivation is to provide metadata for media packets to the wireless
  to compensate for rapid changes in link capacity
  this requires the application to provide some metadata - priority,
  time budget and burst length
  and a means to transport from application to wireless network.
  Hang Shi notes that these methods should apply to the wireline
  access also.
  Sri concurs and notes that cable access has similar fluctuation in
  capacity as wireless networks.
  Lorenzo comments that application runs their own optimizations and
  the metadata/wireless optimization may interfere
  John responds that the process should be with Application control
  and in a cooperative manner, more work needs to be done for managing
  trust and handling the multiple control input/feedback.
  Tianji asks how the information provided in N6/IP transport is
  conveyed in 3GPP to the radio.
  John responds that 3GPP has studied the segment /how to convey
  information to radio over N3. However, the question is how encrypted
  media like HTTP/3 can provide the metadata to the wireless network.

• Transporting IP/UDP Payload-only in VPNs, Zhaofui Zhang, 15min.
  draft-zzhang-bess-ipvpn-payload-only
  use case mobile user plane transportation
  SRv6 transport replacing GTP
  For MPLS, SRv6 header could use an MPLS label. GTP header is
  retained.
  Tianji comments about how the information in GTP header.
  In MPLS, GTP header is kept and in SRv6 most of the parameters are
  mapped.
  Tim Costello, BT asks if there are liaison statements exchanged with
  3GPP?
  Author clarifies that there are no changes in 3GPP and hence not
  sent.

AOB