1 / 17

MEXT WG IETF 82

MEXT WG IETF 82. Agenda and Presentations MONDAY, November 14, 2011 Jouni Korhonen , Julien Laganier. Note Well.

darena
Télécharger la présentation

MEXT WG IETF 82

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MEXT WGIETF 82 Agenda and Presentations MONDAY, November 14, 2011 JouniKorhonen, JulienLaganier

  2. 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.

  3. 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

  4. 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 • WenLuo • 15:35 Use of Proxy Mobile IPv6 for Distributed Mobility Control • Ji-In Kim • 15:40 Re-chartering discussion (30mins) • Overflow queue

  5. Per-Host Locators for Distributed Mobility Management • I-D: draft-liebsch-mext-dmm-nat-phl • Authors: Marco Liebsch • Presenter: Marco Liebsch

  6. 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 betweenIR 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 forreverse NAT at nLMA Src dst:A:1::10 IR/NAT dst:B:1::10 NAT A:x:: B:x:: pMA nMA dst:A:1::10 A:1::10 MN

  7. Approaches to Distributed mobility management using Mobile IPv6 and its extensions • I-D: draft-patil-mext-dmm-approaches • Authors: BasavarajPatil, Carl Williams, JouniKorhonen • Presenter: BasavarajPatil

  8. 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

  9. PMIP Based Distributed Mobility Management Approach • I-D: draft-liu-dmm-pmip-based-approach • Authors: Dapeng Liu, JiongShen, WenLuo • Presenter: WenLuo

  10. Data Delivery From MAG-to-MAG Directly 2. Query CN‘s CoA 3. Tunneling • Uplink Data • (Des: CN’s HoA) CN LMA MAG-CN MAG-MN • MAG-MN determines CoA of CN to tunnel the uplink traffic to MAG-CN directly. MN

  11. Handoff Considerations CN Inform new CoA Moving MAG-CN pMAG nMAG • pMAG informs new CoA of MN when receiving downlink traffic to guarantee data path optimized MN MN

  12. Use of Proxy Mobile IPv6 for Distributed Mobility Control • I-D: draft-sjkoh-mext-pmip-dmc • Authors: SeokJooKoh, Ji In Kim, Hee Young Jung, Youn-Hee Han • Presenter: Ji-In Kim

  13. Use of PMIPv6 for Distributed Mobility Control(draft-sjkoh-mext-pmip-dmc-03) • 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) <S-PMIPv6: Partial DMM> <SD-PMIPv6: Full DMM> presented by Ji-In Kim

  14. 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.

  15. 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..

  16. Re-chartering open discussion • ...

More Related