510 likes | 614 Views
Mobile IPv6 & Cellular Telephony. Charles E. Perkins Nokia Research Center Mountain View, CA USA http://www.iprg.nokia.com/~charliep charliep@iprg.nokia.com. Why Mobile IP?. Both ends of a TCP session (connection) need to keep the same IP address for the life of the session.
E N D
Mobile IPv6 & Cellular Telephony Charles E. Perkins Nokia Research Center Mountain View, CA USA http://www.iprg.nokia.com/~charliep charliep@iprg.nokia.com
Why Mobile IP? • Both ends of a TCP session (connection) need to keep the same IP address for the life of the session. • This is the home address, used for end-to-end communication • IP needs to change the IP address when a network node moves to a new place in the network. • This is the care-of address, used for routing Mobile IP changes the mobility problem into a routing problem • managing a dynamic association between a care-of address to a home address, called a binding
Mobile IPv6 protocol overview • Advertisement from local router contains routing prefix • Seamless Roaming: mobile node always uses home address • Address autoconfiguration for care-of address • Binding Updates sent to home agent & correspondent nodes • (home address, care-of address, binding lifetime) • Mobile Node “always on” by way of home agent Home Agent correspondent node Local Router correspondent node charliep@nokia.com with binding
Mobile IPv6 Design Points • Enough Addresses • Enough Security • Address Autoconfiguration • Route Optimization • Destination Options • Reduced Soft-State
Enough Addresses • 340 undecillion addresses • (340,282,366,920,938,463,463,374,607,431,768,211,456) total! • Billions of IP-addressable wireless handsets • IPv4 address space crunch is already evident • recent unfulfilled request to RIPE • Pressure driving current deployment of NAT • But, multi-level NAT unknown/unavailable • Besides, NAT not useful for always on operation • Even more IP addresses needed for embedded wireless! • Especially interesting for China now • 8 million IPv4 addresses and 50+ million handsets
Enough Security (almost) • Authentication Header mandatory to implement • Needed for Binding Update • Remote Redirect problem • Encapsulating Security Payload mandatory to implement • Key distribution still poorly understood • PKI? • AAAv6 w/ symmetric key?
Routing Prefix MAC address Address Autoconfiguration • A new care-of address onevery link • Stateless Address Autoconfiguration • Link-Local Address Global Address • by changing link-local prefix to advertised routing prefix • Stateful Autoconfiguration (DHCPv6) • Movement Detection • by monitoring advertisement of new prefix • by hints from physical layer and/or lower-level protocol • by monitoring TCP acknowledgements, etc.
Destination Options used by Mobile IPv6 • Destination Options much better than IPv4 options • Binding Updates sent in data packets to Correspondent Nodes • allows optimal routing with minimal packet overhead • SHOULD be supported by all IPv6 network nodes • Binding Update also sent (typically with no data) to Home Agent • replaces IPv4 Registration Request messages • Home Address option • better interaction with ingress filtering • MUST be supported by all IPv6 network nodes • Binding Acknowledgement now sent via ICMP • replaces Registration Reply
Route Optimization • Most Internet devices will be mobile, so we should design for that case for the health of the future Internet • Binding Update SHOULD be part of every IPv6 node implementation, according to IETF specification • Reduces network load by ~50% • (depending on your favorite traffic model) • Route Optimization could double Internet-wide performance! • reduced latency • better bandwidth utilization • reduced vulnerability to network partition • eliminate any Home Agent bottleneck
Improved ICMP messages • IPv4 ICMP returns only 8 payload bytes • IPv4 home agents could not relay errors • insufficient inner header information • some data sources might never find out about broken links • IPv6 ICMP messages return enough data • Also used for anycast home agent discovery
Mobile IPv6 status • Interactions with IPsec fully worked out • Mobile IPv6 testing event Sept 15-17, 1999 • Bull, Ericsson, NEC, INRIA • Connectathon March 2000 – success! • Internet Draft in Last Call • ETSI bake-off October 2-6, 2000
Hierarchical Mobility Agents GMA Home Agent LMA Problem: how to reduce latency due to signaling to Home Agent Solution: Localize signaling to Visited Domain Method: Regional Registration Often, only one level of hierarchy is being considered
Regional registrations Protocol uses Binding Update between the MN and the Visited Domain IPv6 regional registration (Malinen/Perkins) specification uses: • signaling between visited domain routers • authentication between MN, visited network routers and home agent • Destination option (as opposed to the IPv4 solution) Home Agent stores GMA address as the Care-of Address Mobile Node registers only once with Home Agent Mobile node registers locally with GMA
Regional Registrations for IPv6 • two new functional elements: Gateway Mobility Agent, Regional Mobility Agent • participate in registration key distribution to be used for subsequent authentication • GMA has a globally routable address that is used as Mobile Node’s Care Of Address (CoA) in binding updates to Home Agent and Correspondent Nodes • extension to Mobile IP signaling • Regional Binding Update • Automatic determination for crossover router • Novel packet forwarding mechanism
Smooth/Fast/Seamless Handover • Smooth handover == low loss • Fast handover == low delay • 30 ms? • Seamless handover == smooth and fast
SHREQ SHIN SHREP Mobile-controlled seamless handover • Mobile sends SHIN (Seamless Handover (SH) Initiate message) • New Access Router sends SHREP (SH Request) • Previous Access Router sends SHREP (SH Reply) • Regional Registration Destination Option
Context Feature Handover • Seamless Handover has suboptions to control feature handovers: • Header Compression suboption • Managed Buffering suboption • in future … QoS transfer suboption(?) • SHIN contains 32-bit authentication extension • SHREQ relays authentication to Previous Access Router Previous Access Router New Access Router
SHREP SHIN Network Controlled Handover • Previous Access Router sends Unsolicited SHREP to new access router • Mobile node allows transferred context to be finalized by sending an (authenticated) SHIN
Buffer management • Why do we need buffer management? • Avoid loss of packets during handover • Needed for VoIP application • When to start buffering? • When a MN moves to a new access router and there are time critical sessions ongoing • IF MN could request buffering just before moving • Less buffering space required, but… • More prone to sudden failures in communication
Header compression • IP/UDP/RTP(TCP) header compression is compelling in cellular environments • 60/40 byte headers for 20 byte payload for voice • Existing standard, mainly RFC 2508, suffers from • differential encoding of RTP fields from packet to packet: “error propagation” • relying on feedback from the receiver when context is damaged: “delay sensitivity” • When the MN changes its IP point of attachment (aka router), header compression state is needed at the new point of attachment to seamlessly continue header compression operation
Uncompressed packet stream Compressed packet stream Problem Illustration Previous Router New Router discard
Basic framework for header compression in handoff • Rule definition: send a Full Header when an otherwise static field changes (default standard behavior) • The MN sends a full header when CoA changes • The New Router sends full header to the MN • Packets sent to previous CoA are forwarded to the MN with compression
Cellular architectures • Involve SS7 over "control plane" to set up virtual circuits for "user plane" traffic • Are highly optimized for voice traffic (low delay, guaranteed bandwidth), not data • Tend toward "intelligent network" philosophy which for IP is a misplaced locus of control. • Operators want to migrate towards "All-IP" solutions (whatever that means…). • We have a tremendous legacy that needs a lot of attention
AAA and Cellular Telephony • Terminology • Protocol overview • Key Distribution • Scalability and Performance • IETF Status
Terminology • Authentication – verifying a node’s identity • Authorization – for access to resources • according to authentication and policy • Accounting – measuring utilization • Network Access Identifier (NAI) – user@realm • Challenge – replay protection from local attendant • AAAF for foreign domain • AAAH for home domain
AAA & Mobile IP protocol overview • Advertisement from local attendant (e.g., router) • Connectivity request w/MN-NAI from Mobile Node AAAF AAAH Local Attendant Home Agent charliep@nokia.com • Local Attendant asks AAAF for help • AAAF looks at realm within MN-NAI to contact AAAH • AAAH authenticates & authorizes, starts accounting • AAAH, optionally, allocates a home address • AAAH contacts & initializes Home Agent
Key Distribution • New security model • just one security association (SA): mobile node AAAH • Mobile IP needs an association between HA mobile node • 3GPP2, others, want also: • local attendant mobile node • visited mobility agent home agent • AAAH can dynamically allocate all three of these keys • passed back along with authorization and Binding Acknowledgement
AAAH AAAF Home Agent Local Attendant Brokers • Needed when there are 1000’s of domains • NAI is perfect to enable this • AAAF decides whether to use per realm • may prefer bilateral arrangement • iPASS, GRIC • redirect mode also allowable
Scalability and Performance • Single Internet Traversal • Brokers • Eliminate all unnecessary AAA interaction • Handoff between local attendants (routers) • can use existing keys from previous router • Regional Registration • HA can use single regionalcare-of address per domain
Mobile IP/AAA Status • AAA working group has been formed • Working from experience with RADIUS • Mobile IP (v4) AAA requirements draft • Last Call “over”, informational RFC due soon • Several 3G requirements documents online • Mobile IP/AAA extensions draft • AAAv6 Internet Draft(s) submitted • stateless and stateful variations • DIAMETER has been selected for IPv4
Other features (needed for IPv6)b • Mobility-aware Routers used as mobility agents • access control needed at neighbor cache • Regional registration • eliminates most location update traffic across Internet • GGSNs/border routers are candidates for GMA • UDP Lite • Robust Header Compression • AAA HLR adaptation layer • Challenge generation (not from HLR?) • Privacy considerations
HSS 3GPP with GPRS Evolution from cellular packet/GPRS Mobility agent At GGSN Subscription andLocation Directory BSS PSTN CPS/GK GGSN GW BSC/RNC SGSN GPRS Internet Call Processing Server/Gatekeeper Traditional BSS withpacket data QoS enhancements
Evolution from general IP networks Subscriberdatabase AAA Server AAA Server HA HA(mobility within serving ntw) "Slim RNC/BSC" FW CPS FW Internet, Intranets GW One (of many) “ALL-IP” visions PSTN
CDMA2000 3G micromobility AAA Server RNN Subscriberdatabase AAA Server HA PDSN
CDMA2000 3G micromobility • Terminate physical layer distant from “FA” • Protected, private n/w between FA and MN • PDSN (Packet Data Serving Node) ~ GFA • RNN (Radio Network Node) ~ LFA • RNN manages the physical layer connection to the mobile node
CDMA2000 3G Requirements • GRE encapsulation • Reverse Tunneling (RFC 2344) • Registration Update • Registration Acknowledge • Session-specific registration extension • contains MN-ID, type, MN Connection-ID • contains Key field for GRE
CDMA2000 Registration Update • Used for handovers to new RNN • Acknowledgement required • allows PDSN/old RNN to reclaim resources • New authentication extension required • Home address 0 • Home agent PDSN • Care-of address RNN
IMT-2000/UMTS/EDGE reqt’s • Independent of access technology • so should work for non-GSM also • Interoperation with existing cellular • Privacy/encryption (using IPsec) • QoS for Voice/IP and videoconferencing • particular concern during handover • Fixed/mobile convergence desired
IMT-2000 reqt’s, continued • Charge according to QoS attribute request • Roaming to diverse access technologies • e.g., Vertical IP • Route optimization • Identification/authorization based on NAI • Proxy registration for legacy mobile nodes • Signaling for firewall traversal
IMT-2000 reqt’s, continued • Reverse tunneling • Private networks • but, still allow access to networks other than the mobile node’s home network • Dynamic home address assignment • Dynamic home agent assignment • even in visited network • even when roaming from one visited network to another
IPv6 status for cellular telephony • Has been mandated for 3GPP • MWIF recommendation for IPv6 • 3GPP2 study group favorable towards IPv6 • Seems difficult to make a phone call to a handset behind a NAT (not impossible, just expensive and cumbersome and protocol-rich) • IETF design team designated for fast/smooth/seamless handover • AAA adaptation layer for HLR(HSS) under consideration • Smooth evolution from GPRS envisioned
Summary and Conclusions • Future Internet is largely wireless/mobile • IPv6 addressability needed for billions of wireless devices • Mobile IPv6 is far better and more efficient than Mobile IPv4 • Autoconfiguration is suitable for the mobile Internet • Security is a key component for success • Seamless handover needed for VoIPv6 • AAA has a big role to play for cellular rollout We expect Mobile IPv6 (with AAA & Seamless handover) to be the future 3G++ converged wired/wireless, voice/data network
Mobile IPv6 & Cellular Telephony Charles E. Perkins Nokia Research Center Mountain View, CA USA http://www.iprg.nokia.com/~charliep charliep@iprg.nokia.com
Binding Update Correspondent Node Binding Acknowledgement Binding Update Mobile Node Mobile Node Mobile Node Mobile Node Two-Level Visited-Domain Hierarchy Home Link Internet Home Agent Gateway Mobile Agent GMA Previous Access Router New Access Router Visited Domain
Correspondent Node Mobile Node Two-Level Visited-Domain Hierarchy Home Network Internet Home Agent GMA GMA GMA New Access Router Previous Access Router WLAN Visited Domain
Correspondent Node Router AR4 Deep Visited-Domain Hierarchy Internet Home Agent GMA Visited Domain AR1 LMA1 AR1 LMA2 Router Router Router
Start buffering Hand off Buffer Management Process Previous Access Router Correspondent Node IP Network New Access Router
Rtr.Adv Send buffered packets Buffer Management Process Correspondent Node IP Network
Uncompressed header Compressed header Payload NewCoA NewCoA Correspondent Node NewCoA NewCoA Packet Forwarding from previous router Previous Access Router IP Network New Access Router
Packet Forwarding to new CoA R1 CN IP Network R2 Partially compressed header Compressed header Payload CN: Correspondent Node