Network-Based Mobility Extensions WG meeting at IETF83 (Paris, France) WEDNESDAY, March 28, 2012 1300-1500 Afternoon Session I Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) These meeting minutes are courtesy of: 1. Charles Perkins (charles.perkins@earthlink.net) 2. Juan-Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com) Thanks also to the Meetecho team for providing remote access. ------------------------------------------------------------- 1. WG status update: RFC 6463 published -- thanks to Jouni Korhonen for timely contribution and responses RFC Editor's queue: = radius-pmip6 = bulk re-registration IESG Discuss on pmip-lr (localized routing) WGLC completed = netext-access-network-indicator options ----------------------------------- 2. Proxy Mobile IPv6 Extensions to Support Flow Mobility I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos Enhancements for network-based flow mobility Handoff Indicator (HI) allows MAG to indicate to the LMA that the same prefixes should be assigned to mobile node Cleanup of message format; lifetime=0 instead of C flag; no need for refresh (R) flag New Security Considerations text Marco Liebsch and Juan Carlos Zuniga volunteered to review the document ------------------------------------ 3. Prefix Delegation for Proxy Mobile IPv6 I-D: draft-ietf-netext-pd-pmip Carl Williams Mobile Router is a router whose mobility is managed by the network. Since Taipei, text has been revised to avoid terminology issues. Subsection to deal with deletion of delegated prefix. New text in Security Considerations. Raj: will do Chair review and start WGLC. ------------------------------------- Chairs thanked Jari Arkko who has served as the Internet AD for 3 terms. -------------------------------------- 5. PMIPv6 and Network Mobility Problem Statement I-D: draft-bernardos-netext-pmipv6-nemo-ps CJ Bernardos Idea example: move from a mobile device in airport to a bus and keep connectivity as the MAG's IP address moves through connectivity provided by higher-level MAGs. MN keeps its IP address as it moves within the PMIPv6 domain. Many questions... Rajeev: What is new here? CJB: to be explained in the next slides Sri: so if the issue is that the service network changes. You need to change the MAG address CJB: that is solution space, but I agree that is a possibility Jonne: The mobile MAG does not change address, so you don't need this Gaetan: nested tunnels can be used, but no protocol change Sri: you need to change the proxy Laurent Thibault: this is nested tunneling Gaetan: this is an implementation issue, but 5231 does not need changes Carlos: However it is required to specify dual binding cache lookup. Julien: Just the operational sequence of following the protocol... Carlos: please post to the list how to make it work without protocol change ---------------------------------------- 6. Quality of Service Option for Proxy Mobile IPv6 I-D: draft-liebsch-netext-pmip6-qos M. Liebsch nitial draft presented in Taipei Updated draft contains details about: = use cases = protocol operation = QoS option format = ... Exemplary Architecture = LMA incorporated PCEF and uses Policy Control function = cellular access MAG with access bearers = 4 different classes of service = e.g. 11e QoS <---------> IP-based transport network non-cellular access = new IP session PMIPv6 signaling {MAG/WLANC} <--> LMA Raj: Diffserv for Transport Network, but today we don't specify anything Laozi Bo: What is the nature of the QoS information to noncellular? Marco answer: code point Marco: don't want to touch QoS policy on cellular network Julien: 3GPP has put all the controls out of band even when using PMIP, but you are proposing to put it back in band Rajeev: Is this a problem we need to solve in [netext]? recommend: look to see what signaling needs to happen between MAG/LMA We don't Marco: QoS is something functional -- if don't have Gxa/Gxb, need something Dow?: Forget about whether 3GPP exists. Need inband signaling when tunneling can overwrite QoS? Julien: Is it necessary to do this with the mobility signaling? Could it be something else? Raj: want to cut the line -- we just need to answer Julien's question Rajeev: some merit if MAG can do rate limiting facing the wireless Marco: more than DSC marking, also validation Raj: advice -- simplify draft, don't worry about 3GPP, just make case for inband signaling. ----------------------------------------------- 7. PMIPv6 inter-working with WiFi access authentication I-D: draft-liebsch-netext-pmip6-authiwk S. Gundavelli Background: assume we know identity of mobile node Raj: we have Radius extensions in RFC editor queue Sri answer: fair comment, but we need to document how to use Sri: just informational document, not really any new protocol Alper: reasonable idea, maybe other SDOs should be doing this, please take Hotspot into consideration Hui Deng: should say how the authentication work Sri: for some things, should already know the IP address Raj: Maybe web authentication should be done separately Rajeev: the problem re webauth is what do we do with PBU/PBA signaling RFC 5213 assumes completed authentication procedure before registration WLAN is well-accepted access technology (HotSpot, ...) Enable WLAN trusted access = eGPP recommendation for security and PMIP using non-3GPP radio access Document objective: specify AuthN interworking with PMIPv6 = Include other SDOs deployment and recommendations = Include inter-working between WiFI AuthN and operators AAA = Considerations for related Web-authentication Identification of protocol gaps and need for IETF specification Juan-Carlos: what if better ways come up tomorrow ------------------------------------------- 8. Multiple APN Support for Trusted Wireless LAN Access I-D: draft-gundavelli-netext-multiple-apn-pmipv6 Hui Deng = In SP WiFI arch with WLAN access network, MAG can establish PDN connection with APN at any time. Limitation for multiple APN access = IPv6 Prefix Coloring Approach = Solution: MAG establishes PDN connection for default APN, IP address is assigned to the WLAN interface of UE over DHCP = MN launches new applications; based on application triggers, MAG establishes new PDN connections to the indicated APN = MAG creates APN specific connection, translation = Example: MN new flows are established (flow coloring) when MAG sees new application launches. Flows can go to different PDN-gw. = Flow-based Source Address Selection. MAG creates Flow selector based on application. = Data Path considerations = Call Flow example (http needs to go to APN-2) = Limitation: given APN hosting private DNS name space, DNS resolutions will fail == MAG might not have information for some application = Question about charging issues? Answer: operator knows all about these assignments = Jonne: Services from different ISPs works in similar way because operators know exactly where things are going It's harder dynamically, and some things might go the the wrong way. Might start guessing what the user is doing, and might hinder the user from doing many things? = Are you proposing NAT for v6? Ans: no, just for v4. Raj: no protocol changes needed, so no work in [netext] Sri: but every operator might do it a different way. -------------------------------------------------- 9. EAP Attributes for WiFi - EPC Integration I-D: draft-valmikam-eap-attributes-wifi-epc-integration R. Koodli = Trusted WiFI emerging as a new access, but lacks some functions like APNs, Handover Indication, multiple APNs = These are necessary to enable PMIP6 integration into mobile packet core = defines new EAP attributes for existing EAP authentication [TS 33.402] = One attribute: APN selection identifies APN == MN includes AT_VIRTUAL_NETWORK_ID in EAP Response = Behcet: WiFi is a shared link, but PMIP works on point-to-point links == Raj: out of scope for this discussion = Use EAP fast re-auth, can be done any time. MN includes AT_VIRTUAL_NETWORK_REQ in EAP Response/Identity of Fast Re-Auth Connect or disconnect does the "Handover Indicate" Julien: Need to 802.1x re-authentication Alper: Is there activity in IEEE to solve this at MAC layer? Don't want to pass arbitrary attributes over authentication protocols Raj: Ask Gabor, he goes to IEEE Raj: will ask mailing list if we want to take this as a working group document. ---------------------------------------------------- 10. Service Selection for Mobile IPv6 I-D: draft-korhonen-netext-rfc5149bis Jouni Korhonen RFC 5149 ought to be Standards Track PMIP and 5149 have real deployments RFC 5419bis: - echo the Service Selection option back in PBa - encode Service Selection using RFC 1035 domain name - EPC uses Service Selection option as a BCE lookup key - New failure code: MISSING OR UNKNOWN SERVICE versus previous SERVICE AUTHORIZATION FAILED Sri: do not break interoperability Raj: should adopt as WG document? Hum: Strong consensus to adopt as WG document Chairs will follow up on the mailing list