Minutes for DMM at IETF-90
minutes-90-dmm-2

IETF 90 DMM Notes, Thursday 24 

15:25 - 17:20 New individual documents & proposals (75 minutes)
---------------------------------------------------------------

Chair presentation
Status slide
No comments



15:25 - 15:50 Alper (25 minutes) o CSIPTO Introduction o
draft-yegin-ip-mobility-orchestrator o draft-yegin-dmm-ondemand-mobility
Presentation: CSIPTO overview
Presentation: On demand mobility
Presentation: Mobility orchestrator

Introductin to CSIPTO Slide 2 – SIPTO – what is SIPTO.

Slide 3 – CSIPTO – Coordinated SIPTO (RE 13 SA1 work item)

Slide 4 – Use Case 1 – UE moves from eNB1 to eNB2. Old flows (requiring
IP continuity) will use the old PGW1 to maintain source IP address, new
flows (and old flows that do not require IP continuity) can use PGW2
(PGW1 in suboptimal). The PGW1 path will stop to exist when not required
anymore.

Slide 5 – Use case 1 - Higher layer handover methods may be used (MPTCP,
SIP…) for soft handover

Slide 6 – Use Case 2 – before mobility two PDN connections are created.
One without IP continuity guarantee through a local WG (PDN 1 - LGW
which could be co-located at the eNB)and the second with IP address
continuity guarantee (PDN 2 - through the PGW at the core).  Apps that
do not require IP continuity will use PDN1 and apps that do require IP
continuity after handoff us PDN2.

Slide 7 – Use Case 3 – by default, a PDN connection (without IP
continuity guarantee) is set through the LGW. The connection through the
PGW is establish only in the UE requires IP mobility.

Sri regarding use case 1: When is the second PDN connection establish?

Alper:
application-specific – if the application requires IP continuity, the
PDN through PG1 is used, otherwise, the new PDC connection through PG2
is used

Slide 8 – Status of CSIPTO Dapeng: regarding SIPTO what is flat IP

Alper: pushing the MA as closed to the edge as possible.



IP Mobility Orchestrator Slide 2 – Categorization of session continuity
solution. a list of different solutions in different layers (in the IP
layer, Above the IP layer and below the IP layer – link layer)

Slide 3 – Observation: Tradeoff – sub-IP and IP solutions cannot provide
optimized path because of the triangular routing. Above IP can provide
optimized path because the IP address can change and the app will still
maintain the connection.

Carlos: one could do route optimization for IP layer

Alper: right will be addressed in the future.

Charlie: route optimization is layer 3

Alper: true

Slide 4 – Observation: Blocking – lower-layer based solutions inhibiting
operation of upper lay by providing a solution even if it is nor
optimized.

Slide 5: Example of orchestration – using e2e MPTCP with PMIP in access
network. Initially use the original IP address, then after handoff, both
IP addresses are used in parallel and finally, the original path using
IP1 can be dropped.

Sri: MPTCP – each IP address is bound to a different interface 

Alper: no – that is incorrect they can also be in the same interface.  

Kostas: Any measurements? are you planning to ship

Alper: no measurements. Cannot comment on what we are plans


Slide 6 – Basic flow involving the mobile host, source GW, target GW and
corresponding node.

Slide 7 – The IP Mobility Orchestrator – a new entity in the UE for the
discovering the capabilities of the network and CN (in terms of mobility
support)

Slide 8 – Discovery Flow (with the Mobility Orchestrator

Slide 9 – Mobility Protocol Selection Algorithm

Slide 10 – Handover Algorithm

Jouni: Does it include protocol work or only APIs?

Alper: Also protocol work

Dapeng: How can the Orchestrator no if MPTCP is supported (since it
depends on the app)
    
Alper: Through API the app declares what it needs.  

Brian: This is a general capabilities negotiation – are you aware of the
difficulties of standardizing APIs

Alper: It is not easy but it is done in MIF for examples.

Brian: concerned that the APIs will never be standardized.  

Alper: we will have to deal with that.




15:50 - 16:00 Stateless U-plane vEPC, Satoru (10 minutes)
draft-matsushima-stateless-uplane-vepc Presentation: Virtual EPC

Stateless user-plane for vEPC (Virtual Evolved Packet Core)

Slide 2 – Summary of 02-03 updates – routing clarification (sec 3.2) and
Operational classification (Sec 4.1)

Slide 3 – How the I-D fits the re-charter work Item and Milestones

Slide 4 – How the I-D fits the re-charter work Item and Milestones

Sri: Where is the charging (accounting) done

Matsushima-san: No charging in this model. Could add another charging
entity

Marco: About the green arrow: How often will the BGP routes be updated?

Matsushima-san: Not that often

John: Also concerned about charging. May use SDN Matsushima: We will
find a solution

Rajeev: Is the group chartered to do user-plane/control-plane 

Matsushima-san: Yes 




16:00 - 16:10 IP mobility based solutions, Carlos (10 minutes)
draft-bernardos-dmm-pmip (PMIPv6 extensions) draft-bernardos-dmm-cmip
(MIPv6 extensions) Presentation: DMM IP mobility based solutions (PMIP6
& CMIP6)

Slide 2: Where are we in the SMM ocean – difficult to categorize. Could
be re-use PMIPv6 signaling, network and client based or access network
anchoring

slide 3: We extend existing IP mobility protocols – a list of previous
papers about client and proxy MIPv6

Slide 4: Client based DMM solution – with the mobility management pushed
to the edge of the NW

Behcet: I had a draft – did you compare with my draft (I presented in
2012) Carlos: these papers are from 2011

Slide 5: Client-based solution entities – DAR (Distributed Anchor
Router) – first hop router.

Slide 6: Client based solution operations (I) – after handoff the MN can
keep the old address by notifying the corresponding DAR with a BU

Slide 7: Client based solution operations (II) – the MN can also use the
new IP address (anchored in the new DAR) for new sessions

Slide 8: Net-based DMM solution - based on PMIPv6, anchor is pushed to
the edge, user plane is distributed, control plane is centralized

Slide 9: Net-based solution Entities – MAAR (Mobility Anchor and Access
Router) – also one IP address hop from the MN. Concentrates routing, LMA
and MAG functionality. CMD (Central Mobility DB) – manages all MNs in
the domain. Data packets do not flow through it.

Slide 10: Net-based solution. Operations: Initial registration

Slide 11: Net-based solution. Operations: Handover

Slide 12: Net-based solution. CMD as PBU/PBA proxy

Slide 13: Analysis against DMM requirements

Slide 14: Solution implemented see www.odmm.net. Also subscribe to
odmm@odmm.net

Sri: Which extension did you use

Carlos: Extension for authentication 




16:10 - 16:20 Distributed logical interface concept, Carlos (10 minutes)
draft-bernardos-dmm-distributed-anchoring Presentation: Distributed
logical interface

Slide 2: Where are we in the DMM ocean – difficult to categorize

slide 3: What is common to other approaches – routers at the edge assign
locally anchored prefixes to the MNs; compatible with RFC5213; D-GWs
behave as LMA/MAG; transparent to end-host

Slide 4: The Distributed Logical Interface (DLIF) Motivation

Slide 5: The DLIF concept – hide the change of anchor from the MN; each
D-GW is seen to the MN as multiple routers – one per active anchoring
D-GW associated with the MN. Although the MN is physically connected to
one physical router, it sees different routers (logical).

Slide 6: Solution overview (I) 

Alper: What is the difference between this and PMIP 

Carlos: It is similar but the interface is a logical interface and there
are protocol implications.

Sri: What is the interface to receive a different source address

Carlos: This is transparent to the host because it sees a different
router (virtual)

Slide 7: Solution overview (II)

Slide 8: Summary

Alper: What is the protocol work 

Carlos: example: between logical interfaces (virtual routers)

Alper: So how does PMIP6 works 

Carlos: there is only one physical router.




16:20 - 16:40 Controller-based Mobility Architectures, Sri (20 minutes)
http://www.ietf.org/proceedings/89/slides/slides-89-dmm-2.pdf

An update on some off-line discussions…

Slide 1: Stated assumptions 

Kostas: types – OpenFlow is one word, … Sri: fare enough 

Hui: What is the purpose of this work?  

Sri: this is forward looking for next generation. Cannot relate to 5G 

Hui: Is this related to 3GPP or WiFi 

Sri: This is radio agnostic 

Hui: So this could be apply to WiFi or 4G or 5G 

Sri: Yes

Slide 2: DMM – Functional Elements 

Alper: What about an anchor in the CN network 

Sri: Fine, OK 

Charlie: What about authentication is a distributed system – not trivial 

Sri: Agree

Slide 3: Functional architecture with home and access distinction (split
control and data-plane)

Slide 4: Home and Access distinction Removed from the Control Plane
Functions

Rajeev: For a generic mobility controller you only have the
infrastructure. What is the scope of this group.  


Sri: Client and NW based

Slide 5: Home-DPA/Access-DPN collocation 

Hui: It depends on the type of the application. Some require a
permanently allocated IP address.  

Sri: I agree, but this is not always required.  

Alper: We are designing it for the future. In the ACTN BOF discussion
there was a layout of such brake out.  

Sri to Hui: Can you say that in a single operated domain can you say
that this is not relevant?  

Hui: I agree that in this case it is correct.

Slide 6: Home and Access Distinction Removed from both Control/Data
plane functions

Time is running out … Slide 7:..

Slide 8: Home CPA

Slide 9: Home DPA .  .  .  Slide n: Demand for the exposure of states to
the transport NW Subir: Struggling with the objective – transport
network programming?  Sri: We are access agnostic. We can control
routers




16:40 - 17:20 WG next steps, Chairs/WG (40 minutes)
---------------------------------------------------

16:40 - 17:20 Re-chartering discussion o Charter text discussion and
editing o Deployment models, "DMM architecure", functional elements o
Discuss work procedures and how to divide work     

Jouni: We want to complete the re-charter fast to be able to start
working on the solutions. We have to complete the charter work this
month.

Brian: The charter will go through IESG review and a two week phase like
WGLC and then, to IESG final approval. I need it on the agenda before
the 31st of July. In that case, if the WG gets the charter text ready by
the end of July, we can get charter approval by the end of August.

Jouni: We need to agree on the text and the milestone dates.  

Kostas: There is a disconnect between the text that motivates and the
milestones. I agree with the items to work on (the milestones). We only
need to re-word the motivation part.  

Dapeng: Will you be willing to provide edits.  

Kostas: Yes 

Brian: Don’t rely on anyone else. If you have comments – provide text.  

Kostas: I have no problem editing the text. I am concerned that it will
ignite a whole new round of comments.

Brian: Answer about the 4 work items – can the group reach consensus?
Behcet: Each draft will have a deployment section. What is the
deployment model….  .  .  .  

JC: I support the 4 work items. I agree to improve the motivation.  

Jouni: Danny – write in the minutes the Kostas will provide a new edit
by Monday ;-) 

Rajeev: We should think on mobility in general. It’s a mistake to have
text like MIP, PMIP… Use: mobility, end-to-end, network mobility… there
is a consumer of mobility and a provider of mobility.  

Jouni: Good point.  

Hui: About the centralize and distributed control plane. We have to have
something clear for implementation. This is not academic. I don’t see
the clear solution. There are lots of other possibilities that we did
not state.

Sri: in response – We implied that the control plane is virtualized but
we did not require it.  

Jouni: We will have to have some conference calls next week so that we
can conclude by the end of next week.  

Sri: I expect the charter to be broad enough to define a scope. We do
not need a list of documents.  

Jouni: correct


*******************************************************************

IETF 90 DMM Notes, Friday 25
      
Presentation 1: DMM Deployment Model (Anthony Chan)
- Description of Network function virtualization with DP-CP separation.
- Mobility management options: tunneling with optimization

Alper: is it an inter-MAG tunnel?  [Alper says that he will take the
discussion later] 

Sri: as a WG we need to identify functions: do these map to the function
mapping in {sri's} slides?  

A: this is what the functions do, these slides are what they are.  e.g.
anchor allocates IP address in Sri's slides, Anthony's slides are what
the functions are.
      
          
Presentation 2: Enhanced Mobility Anchoring (Anthony Chan)
- Mobility management options: enhanced anchor, move IP address, new IP
  address

Sri: we need to ensure that the goals here should be mapped to the
functional entities (in Sri's slides)
          
          
Presentation 3:  DMM for Wifi users in Fixed Networks (Behcet)
- Motivation: No IP mobility defined for current WiFi/fixed network (and
  other proposals in dmm today are 3GPP centric)
- DMM4WiFi arch: unified gateways (UGW), virtualized control plane (BNG
  app, SDN app)
- Layer 2 mobility - SDN controller calculates shortest path on
  mobility.
- Layer 3 mobility - rfc 5949, predictive and reactive handover. And
  I2RS type of control.

Dapeng: whats the interface between cloud / BR? (slide 6)

B: xmpp/Jabber protocol.

Presentation 4: Demand for exposure of states to the transport network -
Traffic Steering (Marco)
- DP anchor (mobility session of a user network - applies default routes
  ..)
- New mobility session - topological binding of address becomes
  incorrect. Need to handle this.
- Anchor relocation and mobility session transfer while keeping routing
  path short.
- Generic description now, no commitment to protocols yet Alper:
  updating host specific route - so it is in the same category as
  Softbank/Pete's solution?

M: argument is same. But host route does not need to be propagated -
default routes can be used.

Alper: it is a 3rd approach (vEPC, Pete's and then this one).

Sri: is it aligned with softbank's proposal - i.e. with BGP?

Alper: high level view is the same. But details are different - 3GPP,
etc.

Sri: abstract it at semantic level, and leverage work at BGP level.
Otherwise we will be redefining everything.
          
          
Presentation 5: IP mobility protocol for multi homed access (Sri on
behalf of Pierrick)
- Multi-homed RG - BBF work item 2014.546.03: wireless and wireline
  operators and user is multi homed through both with load sharing.
  Hybrid access gateway function.
- BBF assumption is that both the operators are the same.
- Prefix should be reachable through BNG.
- 1:1 mapping to NEMO (with MCoA) is possible.
- BBF requirements: do not split a sub-flow (need per flow/packet
  management)
- Mapping to PMIP: PGW is LMA, BNG is MAG.  John: handling of link
  failure

Sri: yes.

Marco: flow mpobility extension of PMIP required

Sri: yes

M: are there other candidate protocols for flow steering?

Sri: not clear. GRE control plane was proposed, but it requires a high
level control plane.

Behcet: is there another related work related to PCC that can solve
this?

Sri: don't know.

Presentation 6: Asymmetric Extended Route Optimization (AERO) - Fred
Templin
- Different from other proposals - not based on MIP, PMIP, etc.
- RC 6706 is the basis.
- AERO client (handset in airplane), AERO server (embedded in access
  net), AERO relay
- IPv6 is the signaling mechanism, LLA with unique prefixes
- AERO mobility by updating the server's neighbor cache
- Route optimization: predirect message (server is not in loop)
- Internal BGP for updates, long binding to a server.
- Used for corporate users in Boeing and civil aviation (airplane is a
  mobile router)

Bhumip: are the servers virtual?

Fred: can be physical or virtual

B: what is Boeing implementation.

Fred: either or is fine - some are virtual and others physical.

Raj: Does it work for IPv4?

Fred: it uses IPv6 LLA. But IPv4 can be used.

          
          
          
Presentation 7: On Demand Mobility Management (Alper)
- Categories of IP address: fixed, sustained, nomadic
- RFC 5014 - socket API for source address selection defines home /CoA:
  not sufficient for DMM.
- On demand nature not captured in RFC 5014: 3 flags defined for fixed,
  sustained and nomadic.

Sri: is it to replace the existing 5014 flags?

A: no, but old flags will be ignored.

Sri: behavior of existing apps will not be impacted?

A: no.

Dapeng: do we need to care for fixed address?

A: e.g. server that provides fixed IP addresses for users.

Jouni: this is only an API def?

A: this plugs into prefix coloring draft, so there is some on-the-wire
impact.
          
          
Discussion Areas to Work on - 4 areas in Charter:
- Bi-weekly virtual WG meeting proposal
- Small teams on milestones, 2 editors and rest named contributors

Alper: deliverables slide - there may be more than 4 RFC, these are just
areas.

Chair: intention is not to have just 4 RFC. This is a first level of
detail. For eg,, we derive RFC for traffic steering, then we may need
other RFC for protocols

Alper: first call to decide how to split work.

Chair; ok

Sri: first item decides functional model - should be stds track.

Brian: arch and such should be informational.

Sri: what is the impact if something changes to functional elements?

Brian (AD): can mix std, BCPs. Etc should be no problem.

Danny: this is a good approach. Try to divide work and then define table
of contents.

Chair: yes. Too many documents, so the design team /related approach is
needed.

Marco: regarding teams - we need to breakdown these items into technical
areas, each with a team.

Chair: yes. Its likely that multiple document and different docs are
needed.

Sri: in the past - folks sign up but then there is no progress. If there
is no progress, chairs should fire them.

Chair: can be strict.

Chair: PMIPv6 maintenance continues as side track - things that are
broken, and leftover from netext. But not an invitation for new work.

H Chan: how many people are going to be actively involved in this work?

Chair: will ask this in first call.

Sri: given that we don't know the breakup into docs - we should delay
this call.

Marco: people may have different understanding of each item - so one tel
call to converge on these specifics.

Chair: yes.

Chair: will put details on mailing list, and will be aggressive in
setting timeline/conclusion of charter text.