MEXT WGIETF 82

Agenda and Presentations

MONDAY, November 14, 2011

Jouni Korhonen, Julien Laganier

Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF

Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group, BOF or portion thereof, the IESG or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 3978 (updated by RFC 4748) and RFC 3979(updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended

to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 (and RFC 4748) for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best

Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be

made and may be available to the public.

Intellectual Property

When starting a presentation you MUST say if: There is IPR associated with your draft The restrictions listed in section 5 of RFC 3978/4748

apply to your draft When asking questions or commenting on a draft:

You MUST disclose any IPR you know of relating to the technology under discussion

References RFC 5378 and RFC 3979 (updated by RFC 4879) “Note well” text

Agenda

15:10 Introduction and Administration (10mins) 15:20 Presentations (20mins)

15:20 Per-Host Locators for Distributed Mobility Management Marco Liebsch

15:25 Approaches to Distributed mobility management using Mobile IPv6 and its extensions Carl Williams

15:30 PMIP Based Distributed Mobility Management Approach Wen Luo

15:35 Use of Proxy Mobile IPv6 for Distributed Mobility Control Ji-In Kim

15:40 Re-chartering discussion (30mins) Overflow queue

Per-Host Locators for Distributed Mobility Management

I-D: draft-liebsch-mext-dmm-nat-phl Authors: Marco Liebsch Presenter: Marco Liebsch

Key characteristics• Enables IP address continuity after anchor relocation• Solution above mobility anchor level

– No changes to IP mobility protocols

• Utilizes Identifier-Locator-Split concepts• Utilizes NAT instead of IP tunnel between

IR and MN‘s current LMA– No per-packet overhead

• Identifier: Initial HNP/HoA at pMA• Per-Host Locator: HNP/HoA at nMA • Locator is overloaded, as it carries...

– Routable prefix to MN‘s current LMA– MN-specific information as identifier for

reverse NAT at nLMA MN

pMA nMA

Src

IR/NAT

A:x:: B:x::

A:1::10

NAT

dst:A:1::10

dst:B:1::10

dst:A:1::10

Approaches to Distributed mobility management using Mobile IPv6 and its extensions

I-D: draft-patil-mext-dmm-approaches Authors: Basavaraj Patil, Carl Williams, Jouni

Korhonen Presenter: Basavaraj Patil

Approaches to DMM

• The Mobile IP architecture as specified has several issues such as:• Single point of failure• Backhauling of all traffic to a centralized gateway• Added latency

• Distributed mobility management enables a “flat” network architecture

• Mobile IP and associated extensions can form the blueprint for DMM

PMIP Based Distributed Mobility Management Approach

I-D: draft-liu-dmm-pmip-based-approach Authors: Dapeng Liu, Jiong Shen, Wen Luo Presenter: Wen Luo

Data Delivery From MAG-to-MAG Directly

MAG-MN MAG-CN

LMA

MN

1. Uplink Data

(Des: C

N’s HoA)

2. Query CN‘s CoA

3. Tunneling

MAG-MN determines CoA of CN to tunnel the

uplink traffic to MAG-CN directly.

CN

Handoff Considerations

MAG-CN

pMAGnMAG

MN

Inform new CoA

CN

pMAG informs new CoA of MN when receiving

downlink traffic to guarantee data path optimized

MN

Moving

Use of Proxy Mobile IPv6 for Distributed Mobility Control

I-D: draft-sjkoh-mext-pmip-dmc Authors: Seok Joo Koh, Ji In Kim, Hee Young

Jung, Youn-Hee Han Presenter: Ji-In Kim

Two Schemes (both CN and MN are within the same PMIP domain)

New Messages of PMIPv6: PBQ and PQA Proxy Binding Query (PBQ)

MAG LMA (in S-PMIP), MAG MAGs (in SD-PMIP by multicast)

Proxy Query ACK (PQA) LMA MAG (in S-PMIP), MAG MAG (in SD-PMIP)

PMIPv6 Domain

MN CN

1. MN-Connection setup(HoA acquisition)

2. Data

MAG

MAG

MAG

3. PBQ

4. PQA

3. PBQ

6. Data

MAG

3. PBQ

5. Data

PMIPv6 Domain

MN CN

1. MN-Connection setup(HoA acquisition)

LMA

4. Data

MAG

MAG

MAG

2. PBU

3. PBA

5. PBQ

6. PQA

7. Data

8. Data

<S-PMIPv6: Partial DMM> <SD-PMIPv6: Full DMM>

Use of PMIPv6 for Distributed Mobility Control

(draft-sjkoh-mext-pmip-dmc-03)

presented by Ji-In Kim

Re-chartering discussion background

See AD’s email “the future of the MEXT working group” in MEXT mailing list on 28th Oct. Current MEXT is terminating and the one remaining active work

item is moving to a new working group, the Distributed Mobility Management (DMM) working group.

The charter of the group will be changed to focus only on the distributed mobility effort.

Rename the group to "DMM" and put the new charter in effect. Other specifications that people would like to publish beyond

the DMM work, we can offer to AD sponsor them. If there is some significant new activity, we can create new

working groups for that.

Re-chartering discussion; Few considerations to DMM

Current discussion heavily motivated by the existing 3GPP architecture. However, in IETF we cannot assume it as the only architecture to develop for.

Developing new mobility protocols should be avoided: Incremental to existing IETF mobility protocols, be those client- or

network-based. We have several already.. Alternatively may not depend on a specific mobility protocol at all i.e.

non-anchored solutions are also in scope. Make no harm i.e. if a host or a network does not support

DMM, nothing breaks in a current system. Focus on IPv6-based solutions (but not restricted to it):

Something to learn from RFC5555 and RFC5844..

Re-chartering open discussion

...