21-05-0360-00-00001 ieee 802.21 media independent handover dcn:21-05-0360-00-0000 title: card...
TRANSCRIPT
21-05-0360-00-0000 1
• IEEE 802.21 MEDIA INDEPENDENT HANDOVER
• DCN:21-05-0360-00-0000
• Title: CARD Protocol for 802.21 Information Service
• Date Submitted: September 21, 2005
• Presented at IEEE 802.21 session #10, Orange County, California
• Authors : Ajoy Singh (Motorola), Vivek Gupta (Intel)
• Sources (RFC 4066) : Ajoy Singh, Eunsoo Shim, Marco Liebsch ,Hemant Chaskar and Daichi Funato
• Abstract: Provides overview of CARD (RFC 4066) and how it can be used for 802.21 MIH L3 transport
21-05-0360-00-0000 2
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 outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>
21-05-0360-00-0000 3
Contents
• CARD Protocol Overview
• CARD Protocol Architecture Consideration
• CARD Protocol Details
• CARD Protocol Message Structure
• CARD Protocol Security Mechanisms
• Review of 802.21 IS Reference Model
• Proposal to IEEE 802.21 WG
21-05-0360-00-0000 4
Objective
• Give an overview of CARD
• Plan a set future activities to modify (if required) CARD to meet 802.21 L3 Transport requirements
21-05-0360-00-0000 5
CARD Protocol Overview
• CARD Protocol is specified in IETF: RFC 4066
• Basic functionality• Collect and distribute information about the access network, in particular,
information about the current and neighboring L3 and L2 POAs (point of attachments).
• Defines only container protocol (InfoElement not defined) • Defines mechanism for secure information delivery from one CARD
entity to other • Example L3/L2 information elements : Access point Channel numbers,
access router load, IP Version, QoS parameters, Security Protocol info etc.
• Provides an IANA registry that can be used to register various information elements to be carried by the protocol
• Information is distributed from the network entity (assumed to be located at L3 POA) to the mobile node
• Server based CARD (defined in appendix) allows information delivery from CARD Server to Mobile Node and Network L3 POA.
• Information distribution modes• Request/Reply (Solicited) Mode • Broadcast or multicast (Unsolicited) Mode
• …
21-05-0360-00-0000 6
Server-less CARD Protocol Architecture
CARD
CARD
MN-AR CARD Request (1) MN-AR CARD Reply (4)
AR-AR CARD Request (2)
AR-AR Card Reply (3)
• The above diagram describes sequence of message exchange for mobile node initiated information request.
• L3 POA is Access Router (but it is possible to place network component of CARD on any node of Access Network)
CARD
MN (Mobile Node)
Current L3 POA
Neighbor
L3 POA
21-05-0360-00-0000 7
Server-based CARD Protocol Architecture
CARD Server
AR-AR CARD Request (4)
AR-AR CARD Reply (5)
AR- Server CARD Request (2)
MN-AR CARD Request (1)
MN-AR CARD Reply (6)
AR-Server CARD Reply (3)
• Described in appendix of RFC4066
• Describes message exchange for Mobile Initiated information request
for Sever-based CARD protocol
CARD CARD
CARD CARD MN (Mobile Node)
L3 POA (Point of Attachment)
21-05-0360-00-0000 8
CARD Protocol Details
• Possible applications• Fast handoff (seamless handoff)• Load balancing between AR (s) • Inter-technology handovers.• Multi-homing
• CARD messages• Defined for Mobile Node <-> L3 POA
• Uses ICMP for transport• Defined for current L3 POA <-> Neighboring L3 POA communication
• Uses SCTP or UDP for transport• TLV based encoding is supported. • Same TLV options used over MN <-> L3 POA and current L3 POA <->
Neighboring POA interface • Information query options
• Preferences: same as filters (specify what type of information is needed) (e.g. I am interested in Link Type.)
• Requirements: specify the conditions which are information types and required values (e.g. Link type should be 802.11.)
21-05-0360-00-0000 9
CARD Protocol Details
• Uses Sequence number to match CARD Request and CARD Response pair
• Supports reliable message delivery
• Allows CARD entity to send multiple CARD Reply messages in response to single CARD Request if entire content of Reply Message cannot be accommodated in a single ICMP Message. This behavior is only required for ICMP transport.
• CARD Request contains a list of AP Id (s) along with filters indicating the requested information.
• CARD supports two types of filters: • Requirement Sub-Option • Preference Sub-Option
Using combination of Requirement and Preference filters all possible Information Requests can be made
• Reply is sent in response to Request and contains TLV encoded capability information aka InfoElement
• Supports in built security mechanisms to ensure secure information delivery
21-05-0360-00-0000 10
CARD Message Encoding
CARD Sub-options
CARD Option
Transport Header
• Transport Header : IP/UDP, IP/SCTP, ICMP etc.
• CARD Options: CARD Request / CARD Reply
• CARD Sub-options: AVP (attribute Value Pair) for CARD Capabilities aka InfoElements
21-05-0360-00-0000 11
Sub-options
Sequence Number
Type
CARD Request Option Encoding
Length Versions Flags Reserved
• CARD Request is sent by CARD entity to request capability information from other CARD entity.
• MN-AR CARD Request is used by MN to acquire capability information from AR.
• AR-AR CARD Request is used by AR to acquire capability information from its neighboring AR
• AR-Sever CARD Request is used by AR to acquire Capability from CARD Server
21-05-0360-00-0000 12
CARD Reply Option Encoding
Sub-options
Sequence Number
Type Length Versions Flags Reserved
• Sent in response to CARD Request Sub-option• Contains Capability Container sub-options• Capability Container Sub-options contains TLV encoded InfoElements
21-05-0360-00-0000 13
CARD Sub-options Encoding
Sub-Option Type Sub-option Length Sub-options Data
Sub-options:• Container Sub-options:
• L2 ID Sub-options : Encodes L2 ID of AP
• Address : Encodes IPv4/IPv6 address of Access Router
• Capability Container Sub-option : Contains list of TLV containing information elements
• Filter Sub-options:
• Preferences : Carries information about the attribute of interest to the requesting entity
• Requirements : Carries information about attribute value pair required for pre-filtering of capability by L3 POA
• Security Sub-options (Used for SeND Based Authentication):
• Trusted Anchor : Carries name of trusted anchor for which MN has a certificate.
• Router Certificate : Carries one certificate in the path for the current AR or for a CAR
21-05-0360-00-0000 14
AVP(s) …
Capability Container Sub-options Encoding
Sub-Option Type Sub-option Length Context-ID P Resd
Contains multiple requested information element belonging to a single Access Network
Context-ID : Correlates L2 Id with the Information Element
AVPs (Attribute Value Pair): encapsulates 802.21 information elements
21-05-0360-00-0000 15
Attribute Lifetime Data
Capability Attribute Value Pair Encoding
AVP Code AVP Length Reserved
CARD AVP is analogues to 802.21 Information Element
AVP Code : Identifies the attribute uniquely
Lifetime : Lifetime of capability . 0xffff means static capability
Data: Encoded capability information
21-05-0360-00-0000 16
Neighbor Information Neighboring network information
All Technology specific information
Security Link layer security supported
All Technology specific, e.g. WEP in 802.11, 802.11i, PKM in 802.16 UEA in 3G,
Cipher Suites, Authentication_Methods, etc.
Quality of Service Link QoS supported or not by the access network
All E.g. 802.11e, Other Mechanisms
Access Router Info AccessRouterAddress, IPversion, MobilityProtocolSupport, FASupport
Can be part of Higher Layer services
Name of Information Element
Description Media Types
Comments
Example 802.21 Information Elements
21-05-0360-00-0000 17
Using Card Request to Query 802.21 Information
AP-ID1
L2-ID Option SO Length Context-ID (C1) 802.11 AP
Neighbor List Support of Location Services
Preference SO SO Length Security Protocol
Sequence Number of Request Message: SN1
CARDRequest Length Versions Flags Reserved
• Describes CARD Request Message encoding to request following information about access network using AP ID of one of the Access Point (AP-ID1):
• Security Protocol
• Neighbor List,
• Support of Location Service
• Possible to query information about multiple access networks by including AP-Id(s) belonging to multiple access network in same request
• Note: Message format not drawn to the scale
21-05-0360-00-0000 18
Using CARD Reply to deliver 802.21 Information
Attribute Lifetime Data (location Service Info)
Location Service AVP Info Element Length Resvd
Attribute Lifetime Data (802.21 Neighbor List)
Neighbor List AVP Info Element Length Resvd
Attribute LifetimeData (Security Info)
Security Protocol AVP AVP (Info Element) Length Resvd
Capability Cont Sub-opt SO Length Context-ID (C1) P Resvd
Sequence Number of Reply Message : SN1
CARD Reply Length Versions Flags Reserved
• Context-ID identifies the AP-Id (access network) for which the capability information (InfoElements) is being delivered
• Information about each access network is encoded using various AVP(s) and packed inside a single capability container. Multiple capability containers are needed to send information about multiple access networks.
21-05-0360-00-0000 19
CARD Security Mechanisms
• CARD protocol provides secure information delivery using combination of SeND (Secure Neighbor Discovery) and IPSEC mechanism
• SeND (RFC 3971) is used between MN-L3 POA interface for message authentication
• IPSEC ESP is used between current L3 POA- Neighbor L3 POA interface
• ESP with NULL encapsulation is used if only authentication is required
• IKE is used for key management between current L3 POA-Neighbor L3 POA interface
• IPSEC security mechanism can be extended between L3 POA - Server Interface for Server based approach
21-05-0360-00-0000 20
Case 2b: Distributed Information Service with separate Information Database
UE
InformationDatabase
InformationDatabase
Ia
Ia
Ix
Ix
802.21 ISFunction
Network IS Provider
802.21 ISFunction
802.21 ISFunction
Ia`
IEEE 802.21/IETF Scope
IETF Scope(?)
Ia: Interface between UE and Network Ix : Interface between IS Function and Information Database
IEEE 802.21/IETF Scope
Source --- DCN: 21-05-0336-00-0000
Title: Reference Model and Use-Cases for 802.21 Information Service
21-05-0360-00-0000 21
Proposal to IEEE 802.21 WG
Protocol Comparison
MN<-> L3 POA Interface
L3 POA<-> L3 POA Interface
L3 POA<-> Server Interface
CARD (RFC 4066)
CARD MN<-> AR (L3 POA)
CARD L3 POA<-> L3 POA
CARD L3 POA<-> CARD Server
802.21 MIH IS Protocol
Ia
Ia` Ix
• IETF has invested four years work in the area of Information Service and published this as CARD RFC (4066)
• IEEE 802.21 should continue requirements discussion and keep CARD in consideration .
• Extensions or modification of CARD to meet IS requirements is possible.
21-05-0360-00-0000 22
Potential Modifications to CARD To Support 802.21 IS protocol requirements
• Relax the requirements of CARD protocol to allow placement of L3POA CARD entity to any IP node including AP without changing existing CARD protocol
• Make sever-based CARD protocol approach as default CARD protocol assuming server based approach will be favored by 802.21 requirements
• Make additional changes needed to support 802.21 IS protocol
21-05-0360-00-0000 23
Why CARD ?
• CARD is designed to distribute mobility related access network information to handoff control entity
• CARD architecture is flexible enough to accommodate various scenarios being discussed by 802.21 requirement team
• Supports simple Query / Reply Message protocol for secure Information Delivery
• Provides generic encoding mechanism and flexible transport that allows CARD Messages to be transported over any transport layer protocol. e.g., ICMP, UDP and SCTP
• CARD has been implemented and verified in lab setup
• Quicker to modify and enhance an existing protocol than to define a new one
• Last but not least, CARD protocol is already published as RFC and has undergone IETF WG as well as IESG review
21-05-0360-00-0000 24
CARD Next Steps
• Produce an initial document describing how CARD can be enhanced to support 802.21 L3 requirements
• Initial goal is IS, but plan to consider protocol enhancements for Event and Command Service as well
• Work in an ad hoc manner to describe how CARD protocol can be enhanced to support 802.21 L3 requirements
21-05-0360-00-0000 25
21-05-0360-00-0000 26
Preference / Requirements Sub-option Encoding
Sub-Option Type Sub-option Length Preferences
Preferences: List of capability attribute values
Sub-Option Type Sub-option Length Requirements
Requirements: AVP Encoded Requirements
Request / Reply filters are used by MN to request specific capabilities from L3 POA
21-05-0360-00-0000 27
Address and L2 Sub-options Encoding
Address
Sub-Option Type Sub-option Length Context-ID Address Type
L2 Sub-options : Encodes L2 Ids of AP
L2 Type
Sub-Option Type Sub-option Length
L2 ID
Context-ID Status Code
Context-ID: Context-Id is used to associate L2-Id, IP-Address, Capability Information
Status Code: Indicates the Status of L2->L3 mapping < None, Candidate, Match,
Resolver Error >
Address Sub-options : Encodes IPv4/IPv6 address of AR