IEEE 802 21 MEDIA INDEPENDENT HANDOVER DCN 21

  • Slides: 10
Download presentation
IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -09 -0128 -00 -0000 Title: IETF

IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -09 -0128 -00 -0000 Title: IETF Liaison Report Date Submitted: July 16, 2009 Presented at IEEE 802. 21 session #33 in San Francisco Authors or Source(s): Yoshihiro Ohba Abstract: IETF Liaison Report as of July 16, 2009 21 -09 -0128 -00 -0000 1

IEEE 802. 21 presentation release statements This document has been prepared to assist the

IEEE 802. 21 presentation release statements This document has been prepared to assist the IEEE 802. 21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 21. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http: //standards. ieee. org/guides/bylaws/sect 6 -7. html#6> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/faq. pdf> 21 -09 -0128 -00 -0000 2

MIPSHOP WG • DHCP Options for IEEE 802. 21 Mobility Server (Mo. S) discovery

MIPSHOP WG • DHCP Options for IEEE 802. 21 Mobility Server (Mo. S) discovery • draft-ietf-mipshop-mos-dhcp-options-14 • Status: RFC Editor Queue • Locating Mobility Servers using DNS • draft-ietf-mipshop-mos-dns-discovery-07 • Status: AD Follow UP after IESG Evaluation • Three DISCUSS’es • Question about involvement of 802. 21 WG • Clarification about TARGET field • Clarification of “if SRV query did not contain a port number” • Reference to [IEEE 802. 21] is ambiguous • Need SRV service name of MIHIS, MIHES, MIHCS to be in IANA registry to avoid possible future possible conflict • IANA allocation policy conflict between Service Fields and Protocol • [ID. ietf-mipshop-mstp-solution] has to be normative reference 21 -09 -0128 -00 -0000 3

HOKEY WG • Pre-authentication Problem Statement • draft-ietf-hokey-preauth-ps-09. txt • Status: Completed WGLC •

HOKEY WG • Pre-authentication Problem Statement • draft-ietf-hokey-preauth-ps-09. txt • Status: Completed WGLC • HOKEY key distribution • draft-ietf-hokey-mgm-08. txt • Status: Publication requested • Re-charter discussion is ongoing • HOKEY and 802. 21 Integration is one re-charter item 21 -09 -0128 -00 -0000 4

MEXT WG • Multi-Co. A support (multiple Co. As bound to same Ho. A)

MEXT WG • Multi-Co. A support (multiple Co. As bound to same Ho. A) • • I-D. ietf-monami 6 -multiplecoa Status: Approved as Proposed Standard RFC • DSMIPv 6 (MIPv 6 support for dual stack nodes) • RFC 5555 • RFC 3775 bis • • • Discussion to happen on a new standard secure BU mechanism as an alternative to IKEv 2/IPsec Problem Statement: I-D. patil-mext-mip 6 issueswithipsec Solution candidate I-D. korhonen-mext-mip 6 -altsec (Use of HTTPS for bootstrapping IPsec) • Binding revocation binding • • I-D. ietf-mext-binding-revocation Status: Publication Requested • Flow binding (mapping between flow and Co. A) • • I-D. ietf-mext-flow-binding defines transport of the mapping I-D. tsirtsis-mext-binary-filters as a candidate flow description format • HA reliability: I-D. ietf-mip 6 -hareliability 21 -09 -0128 -00 -0000 5

NETLMM WG • Proxy Mobile IPv 6 specification (RFC 5213) • PMIPv 6 heartbeat

NETLMM WG • Proxy Mobile IPv 6 specification (RFC 5213) • PMIPv 6 heartbeat (between MAG and LMA) • I-D. ietf-netlmm-pmipv 6 -heartbeat • Status: RFC Ed. Queue • GRE Key Option for Proxy Mobile IPv 6 • I-D. ietf-netlmm-grekey-option • Status: RFC Ed Queue • IPv 4 support for PMIPv 6 • I-D. ietf-netlmm-pmip 6 -ipv 4 -support: network-based IPv 4 mobility support for MN • Status: Under IESG Evaluation • 3 DISCUSS’es including how LMA and MAG can discover the supported IP version of the peer 21 -09 -0128 -00 -0000 6

MIF (Multiple Inter. Faces) WG • The focus of the WG is on documenting

MIF (Multiple Inter. Faces) WG • The focus of the WG is on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice on hosts attaching to multiple networks • Problem Statement: I-D. blanchet-mif-problem-statement • Analysis: I-D. hong-mif-analysis-scenario 21 -09 -0128 -00 -0000 7

NETEXT WG A WG to work on the following extensions to PMIPv 6 •

NETEXT WG A WG to work on the following extensions to PMIPv 6 • Localized Routing • Problem statement: I-D. liebsch-netext-pmip 6 -ro-ps • Bulk Refresh • LMA Redirection • I-D. korhonen-netext-redirect 21 -09 -0128 -00 -0000 8

NETEXT 2 BOF • Goal: gain understanding of how to support nodes with multiple

NETEXT 2 BOF • Goal: gain understanding of how to support nodes with multiple interfaces (of possible different technologies) in a PMIP 6 domain with the following functionalities • Inter-technology handover • Multihoming • Flow mobility • Possible approaches: • L 2 only • L 3 only • Hybrid 21 -09 -0128 -00 -0000 9

MPTCP (Multipath TCP) BOF • Currently used transport protocols use only one path at

MPTCP (Multipath TCP) BOF • Currently used transport protocols use only one path at a time for sending data • The proposed work is to define the mechanisms to enable transport protocols to use multiple paths simultaneously and to distribute the load among the subflows of each path based on congestion. • In particular, the proposed work is to extend TCP to support simultaneous data exchange through multiple paths • Two complementary approaches are proposed • Two-ended multipath TCP: Both TCP endpoints support multipath TCP • One-ended: multipath TCP: Only one TCP endpoint supports multipath TCP 21 -09 -0128 -00 -0000 10