21-05-0360-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN:21-05-0360-00-0000 Title: CARD Protocol for 802.21 Information Service Date Submitted: September.

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