Transcript 21-05-0360-00-0000-CARD_Overview_2

• 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
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-00-0000
2
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
3
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
4
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
5
Server-less CARD Protocol Architecture
AR-AR CARD Request (2)
Current
L3 POA
Neighbor
CARD
CARD
AR-AR Card Reply (3)
MN-AR CARD Request (1)
MN (Mobile Node)
L3 POA
MN-AR CARD Reply (4)
CARD
• 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)
21-05-0360-00-0000
6
Server-based CARD Protocol Architecture
• Described in appendix of RFC4066
• Describes message exchange for Mobile Initiated information request
for Sever-based CARD protocol
CARD
Server
AR- Server CARD
Request (2)
AR-Server CARD
Reply (3)
AR-AR CARD Request (4)
CARD
MN-AR CARD
Request (1)
AR-AR CARD Reply (5)
CARD
L3 POA (Point of
Attachment)
MN-AR CARD
Reply (6)
CARD
21-05-0360-00-0000
CARD
MN (Mobile Node)
7
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
8
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
9
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-00-0000
10
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.
•
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
11
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-00-0000
12
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
13
Capability Container Sub-options Encoding
Sub-Option Type
Sub-option Length
Context-ID
P
Resd
AVP(s) …
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
14
Capability Attribute Value Pair Encoding
AVP Code
AVP Length
Attribute Lifetime
Reserved
Data
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
15
Example 802.21 Information Elements
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-00-0000
All
E.g. 802.11e, Other Mechanisms
Can be part of Higher Layer services
16
Using Card Request to Query 802.21 Information
CARD
Request
Length
Versions
Flags
Reserved
Sequence Number of Request Message: SN1
Preference SO
SO Length
Neighbor List
L2-ID Option
SO Length
Security Protocol
Support of Location Services
Context-ID (C1)
802.11 AP
AP-ID1
• 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 APId(s) belonging to multiple access network in same request
• Note: Message format not drawn to the scale
21-05-0360-00-0000
17
Using CARD Reply to deliver 802.21 Information
CARD Reply
Length
Versions
Flags
Reserved
Sequence Number of Reply Message : SN1
Capability Cont Sub-opt
SO Length
Security Protocol AVP
Attribute Lifetime
Neighbor List AVP
Attribute Lifetime
Location Service AVP
Attribute Lifetime
Context-ID (C1)
P
AVP (Info Element) Length
Resvd
Resvd
Data (Security Info)
Info Element Length
Resvd
Data (802.21 Neighbor List)
Info Element Length
Resvd
Data (location Service Info)
• 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
18
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 POANeighbor L3 POA interface
• IPSEC security mechanism can be extended between L3 POA Server Interface for Server based approach
21-05-0360-00-0000
19
Case 2b: Distributed Information Service with separate
Information Database
Source --- DCN: 21-05-0336-00-0000
Title: Reference Model and Use-Cases for 802.21 Information Service
Network IS Provider
802.21 IS
Function
UE
Information
Database
Ix
Ia
802.21 IS
Function
IEEE 802.21/
IETF Scope
Ia
IEEE 802.21/
IETF Scope
Ia`
802.21 IS
Function
Information
Database
Ix
IETF Scope
(?)
21-05-0360-00-0000
Ia: Interface between UE and Network
Ix : Interface between IS Function and Information Database
20
Proposal to IEEE 802.21 WG
• 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.
Protocol
Comparis
on
CARD
(RFC
4066)
MN<-> L3 POA
Interface
L3 POA<-> L3
POA Interface
CARD MN<->
AR (L3 POA)
CARD L3
CARD L3 POA<->
POA<-> L3 POA CARD Server
802.21
MIH IS
Protocol
21-05-0360-00-0000
Ia
Ia`
L3 POA<-> Server
Interface
Ix
21
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
22
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
23
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
24
21-05-0360-00-0000
25
Preference / Requirements Sub-option Encoding
Request / Reply filters are used by MN to request specific capabilities
from L3 POA
Sub-Option Type
Sub-option Length
Preferences
Preferences: List of capability attribute values
Sub-Option Type
Sub-option Length
Requirements
Requirements: AVP Encoded Requirements
21-05-0360-00-0000
26
Address and L2 Sub-options Encoding
Address Sub-options : Encodes IPv4/IPv6 address of AR
Sub-Option Type
Sub-option Length
Address Type
Context-ID
Address
L2 Sub-options : Encodes L2 Ids of AP
Sub-Option Type
Sub-option Length
L2 Type
Status Code
Context-ID
L2 ID
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 >
21-05-0360-00-0000
27