Transcript 21-05-0360-01-0000-CARD_Overview_3

• IEEE 802.21 MEDIA INDEPENDENT HANDOVER
• DCN:21-05-0360-01-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-001-0000
1
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-001-0000
2
Background and Overview
• 802.21 WG has acknowledged the need for a higher layer
protocol to enable secure Information Delivery at L3 and above
• We are glad to see that several folks are working to define
requirements for a higher layer transport protocol and building
WG consensus
• We also do realize it is too early to select a protocol or define a
new protocol to support need for 802.21 Information service,
but for the benefit of WG we would like to bring to the notice
of WG a previous attempt to solve such problem by IETF and
provide brief overview of outcome of IETF Work
21-05-0360-001-0000
3
CARD Protocol Overview
• A Protocol for Information Service in a Mobile Environment
• Defined by IETF SeaMoby WG under Transport Area and
published as RFC 4066 on July 2005
• Basic functionality
•
•
•
•
•
•
Collect access network information
Distribute access network information
Provides a container protocol for Information delivery
InfoElement not defined (flexibility for application to define its own)
Provides security mechanism (support SEND and IPSEC)
Provides an IANA registry that can be used to register various InfoElements
to be carried by the protocol
• Supported Information distribution model:
•
•
Request/Reply (Solicited) Mode
Broadcast or multicast (Unsolicited) Mode
21-05-0360-001-0000
4
CARD To Support 802.21 IS
• Server based CARD defined in appendix of RFC4066 can be used
• Describes message exchange between UE and Information Server
Single hop Model
Network IS Provider (NISP)
UE
802.21
IS Function
(Client)
802.21
IS Function
(Server)
CARD Request /
Reply
Information
Database
Ix
Multi hop Model
UE
802.21
IS Function
(Client)
Network IS Provider (NISP)
Proxy NISP
CARD Request
Reply
21-05-0360-001-0000
802.21
IS Function
(Proxy)
CARD Request
/ Reply
802.21
IS Function
(Server)
Information
Database
Ix
5
CARD Protocol Details
• Possible applications:
•
•
•
•
Fast handoff (seamless handoff)
Load balancing between AR (s)
Inter-technology handovers
Multi-homing
• CARD messages
•
Defined for communication between Mobile Node <-> Network CARD Entity
•
•
Uses ICMP for transport
Defined for communication between two network CARD entities
•
Uses SCTP or UDP for transport
•
TLV based encoding is supported.
Same message encoding used over MN <-> Network CARD entity and
Network CARD Entity <-> Network CARD Entity 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-001-0000
6
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-001-0000
7
CARD Message Encoding
• Transport Header : IP/UDP, IP/SCTP,
Transport Header
ICMP etc.
• CARD Options: CARD Request / CARD
Reply
CARD Option
• CARD Sub-options: AVP (attribute Value
Pair) for CARD Capabilities aka
InfoElements
CARD Sub-options
21-05-0360-001-0000
8
CARD Request Option Encoding
Type
Length
Versions
Flags
Reserved
Sequence Number
Sub-options
•
CARD Request is sent by CARD entity to request capability information from other CARD
entity.
21-05-0360-001-0000
9
CARD Reply Option Encoding
Type
Length
Versions
Flags
Reserved
Sequence Number
Sub-options
• Sent in response to CARD Request Sub-option
• Contains Capability Container sub-options
• Capability Container Sub-options contains TLV encoded InfoElements
21-05-0360-001-0000
10
CARD Sub-options Encoding
Sub-Option Type
Sub-option Length
Sub-options Data
Sub-options (example)
•
•
Container Sub-options:
•
L2 ID Sub-options : Encodes L2 ID of AP / BTS
•
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
21-05-0360-001-0000
11
Example 802.21 Information Elements
Transported by CARD
Name of Information
Element
Description
Media
Types
Comments
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
Access Router Info
AccessRouterAddress,
IPversion,
MobilityProtocolSupp
ort, FASupport
21-05-0360-001-0000
All
E.g. 802.11e, Other Mechanisms
Can be part of Higher Layer services
12
Some Thoughts
• Continue requirements discussion in IEEE
802.21 WG
• Upon completion of requirements discussion,
discuss various existing protocol to decide if an
existing protocol can be used or enhanced to
support 802.21 transport requirements
• Work with IETF to enhance existing protocol or
define new protocol if there is need to do so
21-05-0360-001-0000
13