itssv6deliverable itssv6strepgrantagreement210519 d2.2 ... · standards from the international...

ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs

http://www.itssv6.eu/

ICT-2009.6: ICT for Mobility, Environmental Sustainability

and Energy Efficiency

ITSSv6 Deliverable

ITSSv6 STREP Grant Agreement 210519D2.2: Preliminary System Specification

DATE 22nd May 2012CONTRACTUAL DATE OF DELIVERY TO THE EC M12 (31.01.2012)ACTUAL DATE OF DELIVERY TO THE EC M14 (31.03.2012)EDITOR, COMPANY Thierry Ernst, InriaDOCUMENT CODE ITSSv6-D.2.2-PreliminarySystemSpecification-v1.1SECURITY Public

Project Coordinated by Thierry Ernst - Mines ParisTech / InriaE-mail: [email protected]

Document History

Release Date Reason of change Status Distribution1.0 31/03/12 Final consolidated version Final Internal1.1 01/05/12 Alignment with other deliverables Final EC

1

Contents

Executive summary 9

Contributors 10

1 Introduction 111.1 The ITSSv6 project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Purpose of this deliverable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Objectives and contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 ITS station reference architecture 142.1 ITS station reference architecture overview . . . . . . . . . . . . . . . . . . . . 14

2.1.1 OSI-like layered architecture . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2 Types of ITS stations . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.3 ITS stations hosts and routers . . . . . . . . . . . . . . . . . . . . . . . 162.1.4 ITS stations and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 ITS station networking and transport . . . . . . . . . . . . . . . . . . . . . . . 182.3 ITS station management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 ITS station security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 ITS station access technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 ITS station facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 ITS station applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.8 ITS station service access points (SAP) . . . . . . . . . . . . . . . . . . . . . 22

3 ITS station IPv6 networking design 253.1 IPv6 networking in the ITS station architecture: ISO 21210 . . . . . . . . . . 253.2 IPv6 networking issues in the ITS station standards . . . . . . . . . . . . . . 27

3.2.1 IPv6 networking issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 ITS station architecture issues . . . . . . . . . . . . . . . . . . . . . . 30

3.3 IPv6 protocol block design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 ITS station management entity design . . . . . . . . . . . . . . . . . . . . . . 333.5 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2

4 Path and flow management 354.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Path management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4 Flow management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1 Flow requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.2 Flow registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.3 Flow statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5 Path selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.1 Flows mapped to paths . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.2 Flow policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Local ITS station information table . . . . . . . . . . . . . . . . . . . . . . . . 454.7 Neighbor ITS station information table . . . . . . . . . . . . . . . . . . . . . . 474.8 Path information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.9 Flow requirement table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.10 Flow information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.11 Flow statistics table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.12 Flow policy table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Module IPv6 adaptation agent 565.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 Parameters maintained at the network layer . . . . . . . . . . . . . . . . . . . 57

5.2.1 Parameters maintained at the IPv6 layer . . . . . . . . . . . . . . . . . 575.2.1.1 Locator and identifier . . . . . . . . . . . . . . . . . . . . . . 575.2.1.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 Parameters maintained at the GeoNetworking layer . . . . . . . . . . . 595.3 Mapping between management and IP parameters . . . . . . . . . . . . . . . 59

5.3.1 MN-REQUEST function parameters and corresponding events . . . . 595.3.2 MN-COMMAND function parameters and corresponding actions . . . 59

5.4 IPv6 path management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.4.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 IPv6 flow management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.5.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.5.2 Feedback and update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Module IPv6 traffic classifier 666.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.2 Relation between IPv6 networking modules . . . . . . . . . . . . . . . . . . . 666.3 IPv6 packets classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.5 Policy Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Module IPv6 forwarding 697.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.2 Flow policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2.1 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.3 Required actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8 Module IPv6 mobility support 728.1 IPv6 network mobility basic support (NEMO) . . . . . . . . . . . . . . . . . . 728.2 IPv6 mobile edge multihoming (MCoA) . . . . . . . . . . . . . . . . . . . . . 738.3 Required actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

9 Module IPv6 ad-hoc networking 769.1 IPv6 Internal Network Prefix Discovery (INPD) . . . . . . . . . . . . . . . . . 76

9.1.1 INPD: Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.1.2 INPD: Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.1.3 INPD: Interaction with other modules . . . . . . . . . . . . . . . . . . 789.1.4 INPD: Message flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.1.4.1 INPD: Proactive mode message flows . . . . . . . . . . . . . 799.1.4.2 INPD: Reactive mode message flows . . . . . . . . . . . . . . 79

10 Module IPv6 over GeoNetworking 8110.1 IPv6 over GeoNetworking: description . . . . . . . . . . . . . . . . . . . . . . 81

10.1.1 GeoNetworking Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 8210.2 Required actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

11 Module IPv6 security 8411.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8411.2 ITU’s definition of security services and mechanisms . . . . . . . . . . . . . . 85

11.2.1 Security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8511.2.2 Security mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

11.3 Security services offered by the IPv6 security module . . . . . . . . . . . . . . 8611.4 IPv6 security protocols implementing security services . . . . . . . . . . . . . 8711.5 Interaction with other modules and entities . . . . . . . . . . . . . . . . . . . 90

11.5.1 Interaction with ITS station management entity . . . . . . . . . . . . . 9211.5.2 Interaction with ITS station security entity . . . . . . . . . . . . . . . 9211.5.3 Interaction with other IPv6 modules . . . . . . . . . . . . . . . . . . . 92

11.6 Pseudonym configuration at the IPv6 layer . . . . . . . . . . . . . . . . . . . . 9311.6.1 Pseudonym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9311.6.2 Pseudonym configuration . . . . . . . . . . . . . . . . . . . . . . . . . 94

11.6.2.1 Pseudonym update due to mobility . . . . . . . . . . . . . . . 9411.6.2.2 Pseudonym change due to the mobility lifetime expiration . . 9411.6.2.3 Pseudonym change due to the pseudonym lifetime expiration 94

11.6.3 Example of pseudonym change at the IPv6 layer . . . . . . . . . . . . 9411.7 Access Control Mechanisms for IPv6 communications . . . . . . . . . . . . . . 97

11.7.1 General overview of access control . . . . . . . . . . . . . . . . . . . . 9711.7.2 Access control mechanisms provided by the IPv6 security module . . . 9711.7.3 Example of network access control with EAP authentication support . 99

12 Module IPv6 multicasting 10112.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10112.2 Required actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

13 Module IPv4-IPv6 interoperability 10313.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10313.2 Required actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

14 MN-SAP: Interface between Management and Network entities 10514.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10514.2 N-Parameter exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

14.2.1 MN-SET command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10614.2.1.1 MN-SET.request . . . . . . . . . . . . . . . . . . . . . . . . . 10714.2.1.2 MN-SET.confirm . . . . . . . . . . . . . . . . . . . . . . . . . 107

14.2.2 MN-GET command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10714.2.2.1 MN-GET.request . . . . . . . . . . . . . . . . . . . . . . . . . 10714.2.2.2 MN-GET.confirm . . . . . . . . . . . . . . . . . . . . . . . . 108

14.2.3 N-Parameter for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10814.2.4 N-Parameters for GeoNetworking . . . . . . . . . . . . . . . . . . . . . 109

14.3 Parameters and primitives for path and flow management . . . . . . . . . . . 11214.3.1 MN-REQUEST and MN-COMMAND . . . . . . . . . . . . . . . . . . 11214.3.2 MN-REQUEST STAGeoNot . . . . . . . . . . . . . . . . . . . . . . . . 11214.3.3 MN-REQUEST STATopoNot . . . . . . . . . . . . . . . . . . . . . . . 11314.3.4 MN-REQUEST STAServNot . . . . . . . . . . . . . . . . . . . . . . . 11314.3.5 MN-REQUEST PathNot . . . . . . . . . . . . . . . . . . . . . . . . . 11414.3.6 MN-REQUEST PathMetricNot . . . . . . . . . . . . . . . . . . . . . 11514.3.7 MN-REQUEST FlowStatistics . . . . . . . . . . . . . . . . . . . . . . 11614.3.8 MN-COMMAND PathMNGT . . . . . . . . . . . . . . . . . . . . . . . 11614.3.9 MN-COMMAND FlowClassificationRule . . . . . . . . . . . . . . . . 11614.3.10MN-COMMAND FlowPolicy . . . . . . . . . . . . . . . . . . . . . . . 11614.3.11MN-COMMAND FlowFeedback . . . . . . . . . . . . . . . . . . . . . 11714.3.12MN-COMMAND STAServDiscov . . . . . . . . . . . . . . . . . . . . 117

15 SN-SAP: Interface between Networking & Transport Layer and SecurityEntity 11915.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11915.2 Service Interfaces of the SN-SAP . . . . . . . . . . . . . . . . . . . . . . . . . 11915.3 SN-SAP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A Candidate technologies for access control in ITS 121

B Terminology 123

C List of acronyms 127

Bibliography 131

List of Figures

2.1 Simplified ITS Station (ITS-S) Reference Architecture . . . . . . . . . . . . . 162.2 Detailed ITS Station (ITS-S) Reference Architecture . . . . . . . . . . . . . . 172.3 Types of ITS stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 ITS station communication management . . . . . . . . . . . . . . . . . . . . . 192.5 ITS Station Service Access Points (SAP) . . . . . . . . . . . . . . . . . . . . 222.6 MN-Command and MN-Request service primitive . . . . . . . . . . . . . . . . 232.7 MN-COMMAND Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.8 MN-REQUEST Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 IPv6 functional modules in ISO 21210 . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Definition of path in the ITS station architecture . . . . . . . . . . . . . . . . 364.2 Overview of the relation between ITS station management entity (SME) and

other entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Relation between management parameters and identifiers . . . . . . . . . . . 384.4 Cross-layer information flow for path and flow management . . . . . . . . . . 394.5 Controllable communication points . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Possible paths between two vehicle ITS stations . . . . . . . . . . . . . . . . . 414.7 Network around vehicle ITS station . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 IPv6 Adaptation Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 Procedure of Path Management . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Routing architecture of the IPv6 networking stack. . . . . . . . . . . . . . . . 645.4 Procedure of feedback and flow management. . . . . . . . . . . . . . . . . . . 65

8.1 IPv6 session continuity with NEMO Basic Support . . . . . . . . . . . . . . . 738.2 IPv6 mobile edge multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . 74

9.1 Message Flow Example in INPD Proactive Mode. . . . . . . . . . . . . . . . . 789.2 Message Flow Example in the INPD Reactive Mode: A node sends its INPS

message to all neighbor nodes to quickly obtain neighbor node’s internal net-work prefixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.3 Message Flow Example in the INPD Reactive Mode: A node sends its INPSmessage to a specific node to quickly obtain the specific node’s internal networkprefix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6

11.1 Security services achieved by security mechanisms at the IPv6 layer . . . . . . 8811.2 Mapping of security services to types of IPv6 node . . . . . . . . . . . . . . . 8911.3 Mapping of security mechanisms to types of Pv6 node . . . . . . . . . . . . . 8911.4 Security mechanisms provided by IPv6 security protocols . . . . . . . . . . . . 9011.5 Mapping of security protocols to types of IPv6 node . . . . . . . . . . . . . . 9111.6 Mapping of security protocols according to the type of interface (internal and

external) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9111.7 Considered network topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9411.8 Pseudonym change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9511.9 Vehicle ITS accessing to Internet through a roadside ITS station . . . . . . . 100

14.1 Interface Between the Management Entity and the Network Layer . . . . . . . 10614.2 N-Parameters for GeoNetworking . . . . . . . . . . . . . . . . . . . . . . . . 11014.3 Cross-layer information flow for path and flow management . . . . . . . . . . 113

15.1 Relation with the ITS station security entity through SN-SAP . . . . . . . . . 119

A.1 EAP Authentication Framework . . . . . . . . . . . . . . . . . . . . . . . . . 122

List of Tables

4.1 Local ITS station information table . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Neighbor ITS station information table . . . . . . . . . . . . . . . . . . . . . . 474.3 Path information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4 52 CI parameters specified in [? ] . . . . . . . . . . . . . . . . . . . . . . . . 504.5 Flow requirement table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.6 Flow information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.7 Flow statistics table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.8 Flow policy table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1 Mapping between Events in IPv6 Network Protocol Block and MN-REQUEST 605.2 Mapping between Actions in IPv6 Network Protocol Block and MN-COMMAND 61

14.1 MN-SET.request parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10714.2 MN-SET.confirm parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 10814.3 MN-GET.request parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 10814.4 MN-GET.confirm parameter description . . . . . . . . . . . . . . . . . . . . . 10914.5 New MN-REQUESTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11214.6 New MN-COMMANDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11214.7 Parameters of MN-REQUEST “STAGeoNot” . . . . . . . . . . . . . . . . . . 11414.8 Parameters of MN-REQUEST “STATopoNot” . . . . . . . . . . . . . . . . . . 11414.9 Parameters of MN-REQUEST “STAServNot” . . . . . . . . . . . . . . . . . . 11514.10Parameters of MN-REQUEST “PathNot” . . . . . . . . . . . . . . . . . . . . 11514.11Parameters of MN-REQUEST “PathMetricNot” . . . . . . . . . . . . . . . . . 11614.12Parameters of MN-REQUEST “FlowStatistics” . . . . . . . . . . . . . . . . . 11614.13Parameters of MN-COMMAND “PathMNGT” . . . . . . . . . . . . . . . . . . 11714.14Parameters of MN-COMMAND “FlowClassificationRule” . . . . . . . . . . . . 11714.15Parameters of MN-COMMAND “FlowPolicy” . . . . . . . . . . . . . . . . . . 11814.16Parameters of MN-COMMAND “FlowFeedback” . . . . . . . . . . . . . . . . 11814.17Parameters of MN-COMMAND “STAServDiscov” . . . . . . . . . . . . . . . . 118

15.1 Description of SN-Request.No. . . . . . . . . . . . . . . . . . . . . . . . . . . 120

B.1 Terminology for IPv6 Networking . . . . . . . . . . . . . . . . . . . . . . . . . 126

8

Executive summary

This document is a public deliverable (D2.2) of ITSSv6 (IPv6 Station Stack for CooperativeITS Field Operational Tests), a FP7 European Project, which aims at specifying and develop-ing an enhanced IPv6 protocol stack optimized for Intelligent Transportation Systems (ITS)use cases complying with Cooperative ITS (C-ITS) standards. It presents a preliminary spec-ification of the IPv6 protocol block of the ITS station networking & transport layer of the ITSstation reference architecture jointly defined by the International Organization for Standard-ization (ISO) (Technical Committee 204) and the European Telecommunications StandardsInstitute (ETSI) (Technical Committee ITS) for C-ITS communications. The IPv6 protocolblock is a collection of features corresponding mostly to protocols specified by the InternetEngineering Task Force (IETF). These features are selected specifically to meet ITS usecases and are arranged into a set of modules performing a subset of the required functions.The arrangement of the IPv6 protocol block into modules allows to easily specify what isthe minimum set of modules to be implemented for each type of IPv6 node composing ITSstations (vehicle ITS stations, roadside ITS stations, central ITS stations and personal ITSstations). Types of IPv6 nodes include IPv6 routers, presently access router (AR), mobilerouter (MR), border router (BR), home agent (HA) and IPv6 hosts. Modules defined in theISO standard CALM: IPv6 Networking [ISO-21210] are taken as an input and extended withnew features required to secure and to optimize IPv6 communications and to fulfill otherneeds expressed by C-ITS Field Operational Tests (FOTs). The preliminary pecification re-ported in this document are being contributed to both ISO, CEN and ETSI. The presentspecification of the IPv6 protocol block will be revised, taking into account standardizationprogress and reported in a new document entitled ITSSv6 D2.4: Final System Specificationto be published in February 2014. The revision will specify the modules which are not yettotally detailed and will include IPv6 features required for personal ITS stations which arenot yet treated.

9

Contributors

The following ITSSv6 members have contributed to this deliverable:

• Thierry Ernst, from Mines ParisTech / Inria.

• Manabu Tsukada, from Inria.

• Jong-Hyouk Lee, from Inria.

• Emmanuel Thierry, from Institut Telecom.

• Fernando Pereiguez, from University of Murcia.

• Antonio F. Skarmeta, from University of Murcia.

10

CHAPTER 1

Introduction

1.1 The ITSSv6 project

ITSSv6 (IPv6 Station Stack for Cooperative ITS Field Operational Tests (FOTs) is an Euro-pean Project (STREP) from the 7th Programme Framework (Grant Agreement 270519), Call6 (ICT-2009.6: ICT for Mobility, Environmental Sustainability and Energy Efficiency) startedin February 2011 and lasting until January 2014. The project is coordinated by Institut Na-tional de Recherche en Informatique et en Automatique (Inria) and gathers Universidad deMurcia (UMU),Institut Mines Telecom (IT), lesswire (LW), Magyar tudomanyos akademiaszamitastechnikai es automatizalasi kutato intezet (SZTAKI), Schalk & Shalk OG (IPTE)and Bluetechnix Mechatronische Systeme GmbH (BT) (Bluetechnix in short).

The objective of the ITSSv6 project is to deliver an optimized IPv6 implementation ofETSI / ISO ITS station reference architecture. ITSSv6 builds on existing standards fromETSI, ISO and IETF and IPv6 software available from the CVIS and GeoNet projects. TheIPv6 lTS station stack provided by ITSSv6 supports at least 802.11p and 2G/3G media typesand is configured differently according to the role played by the ITS station (roadside, vehicle,central). The tasks of ITSSv6 are to:

• Gather third party users into a common User Forum to collect user’s requirements;

• Enhance existing IPv6-related ITS station standards and specification of missing fea-tures;

• Implement IPv6-related ITS station standards;

• Validate the implementation and assess its performance;

• Port the IPv6 ITS station stack to selected third party platforms;

• Support third parties in the use of the IPv6 ITS station stack.

Publishable material of the ITSSv6 project (public deliverables, newsletters, presentationsmade at conferences or workshops, information about events) are made available on theproject’s web site (http://www.itssv6.eu) as it becomes available.

11

D2.2: Preliminary System Specification

1.2 Purpose of this deliverable

This deliverable presents the IPv6 system requirements and the specification of features.It is the output of tasks T2.1 System Requirement Analysis and T2.2 IPv6 protocol stackspecification:

• T2.1: System Requirement Analysis Application requirements in terms of IPv6networking are analyzed considering output from FP6 projects (CVIS, SafeSpot, Coop-ers and SeVeCom) and objectives of known FOTs. Functionalities to be provided inthe ITS Station architecture (ISO and ETSI) are analyzed at all layers of the archi-tecture and the IPv6 networking layer features of the ITS Station are classified intothree classes according to the expected complexity, known availability of a protocol-level specification and implementation, and urgency (MS21). Needs and capabilities interms of hardware (CPU, memory, ...), network architecture (public or private accessnetwork, in-vehicle network or single in-vehicle node, ...), wireless technologies (802.11p,WiMaX, Satellite, 2G/3G, ...) and Internet connectivity (availability of IPv6, ...) ofthird parties identified in T6.1 are considered. This work is reported in D2.2 and revisedin D2.4.

• T2.2: IPv6 protocol stack specification IPv6 networking features identified andclassified in T2.1 are fully specified. Specifications are written at the ITS stationarchitecture level if protocol-level specifications already exists (Class-1 items) in orderto ease their integration into ITS Station specification (ISO and ETSI). For featuresrequiring extensions (Class-2 items), these extensions are specified in the context ofthe ITS Station architecture. For features missing a specification (Class-3 items), aprotocol-level specification is written and proposed in scientific papers, possibly to therelevant SDO (likely IETF). Specifications are formatted into IETF internet-drafts styleand passed to WP3 (MS22 and MS23) for implementation and WP6 (MS22, MS23 andMS24) for potential standardization in the relevant SDO. This work is reported in D2.2and revised in D2.4.

1.3 Objectives and contributions

After careful analysis of the FOT needs and existing ITS standards related to IPv6, wepropose, from a specification point of view, a new design of the IPv6 protocol block ofthe ITS station networking & transport layer. The new IPv6 protocol block, as comparedto the current IPv6 networking standard [ISO-21210], is interacting with the ITS stationmanagement entity and the ITS station security entity through respectively the MN-SAP andSN-SAP which are also defined. New modules are proposed within the IPv6 protocol block,to allow IPv6 over GeoNetworking, IPv6 multicast, IPv6 policy routing and IPv6 securitywhile existing modules are brushed up and extended. These are specified, and specificationshave been provided to ISO for insertion in standards (IPv6 networking security [ISO-16788],IPv6 networking optimization [ISO-16789], ITS station architecture [ISO-24102], ITS stationmanagement [ISO-21217] and IAnalysis of Pv6 for networking [ETSI-TR-101-555]). Themajor contributions of the ITSSv6 project for the specification of IPv6 networking are, inthe present version of this deliverable:

• An analysis of the limitations of the IPv6-related ISO standard [ISO-21210];

• A new organization of the IPv6 networking protocol block;

ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 12/134


• The specification of a protocol for direct routing between adjacent ITS stations (INPD);

• The definition of the concept of path and flow and the specification of path and flowmanagement;

• The specification of flow management within the IPv6 protocol block;

• The specification of the IPv6 security module within the IPv6 protocol block;

• The specification of the functions and parameters required for the interaction betweenthe IPv6 protocol block and the ITS station management entity (MN-SAP);

• The specification of the functions and parameters required for the interaction betweenthe IPv6 protocol block and the ITS station security entity (SN-SAP);

1.4 Structure of the document

The present document is structured as follows:

• Chapter 2 describes the ITS station reference architecture, as currently specified in ISOand ETSI standards;

• Chapter 3 analyzes the current IPv6-related standards on IPv6 networking, discussestheir limitations, and provides a new design of the IPv6 networking protocol block;

• Chapter 4 details how communication paths are determined and flow mapped to a givenpath;

• Chapter 5 details the IPv6 adaptation agent module;

• Chapter 6 details the IPv6 traffic classifier module;

• Chapter 7 details the IPv6 forwarding module;

• Chapter 8 details the IPv6 mobility support module;

• Chapter 9 details the IPv6 adhoc networking module;

• Chapter 10 introduces the IPv6 over GeoNetworking module;

• Chapter 11 details the IPv6 security module;

• Chapter 12 introduces the IPv6 multicasting module;

• Chapter 13 introduces the IPv4-IPv6 transition module;

• Chapter 14 details the Service Access Point (SAP) between the ITS station managemententity and IPv6 networking protocol block (MN-SAP);

• Chapter 15 details the Service Access Point (SAP) between the ITS station securityentity and IPv6 networking protocol block (SN-SAP);

• Appendix B provides the definition of the terms necessary to specify IPv6 networking;

• Appendix C provides the list of acronyms;

• References are provided at the end of this document.


CHAPTER 2

ITS station reference architecture

In this chapter, we describe the ITS station reference architecture as currently defined instandards from the International Organization for Standardization (ISO) (Technical Com-mittee 204) and the European Telecommunications Standards Institute (ETSI) (TechnicalCommittee ITS).

2.1 ITS station reference architecture overview

In an effort towards harmonization, the European ITS community (EC’s funding programsFP6 and FP7, the Car-to-Car Communication Consortium) and international standardiza-tion bodies (ISO TC204 WG16 and ETSI TC ITS) have invested significant effort into thespecification of a communication architecture suitable for a variety of C-ITS needs. Thisharmonization effort, initially conducted by COMeSafety in 2010 (European FP6 SpecificSupport Action), considered early work performed by ISO TC204 WG16 and other stake-holders from various FP6 and FP7 European Projects (CVIS, SafeSpot, Coopers, GeoNet,SeVeCom) and organizations (e.g. C2C-CC).

This has led to the definition of the ITS station reference architecture at both ETSI TCITS [ETSI-EN-302-665] and ISO TC 204 [ISO-21217]. This architecture is illustrated onFigure 2.1. Both ISO and ETSI architecture standards are based on the same terminologyand tend to converge although there are still remaining differences between the two. This lackof consistency shall disappear as standards are revised (revision is undergoing as of February2012).

The design principle of this communication architecture is to support simultaneously adiversity of applications of all types (road safety, traffic efficiency and comfort / infotainment)and to offer them a diversity of access technologies including cellular (2G, 3G), microwave(5 GHz IEEE 802.11p vehicular WiFi, 2.5 GHz IEEE 802.11n urban WiFi), satellite, infra-red, 60 GHz millimeter-wave and possibly others, for a variety of communication scenarios(vehicle-based, roadside-based and Internet-based). These access technologies provide wiredand wireless broadcast, unicast and multicast communications between mobile stations, be-tween mobile and fixed stations and between fixed stations.

A fundamental advantage of this design concept over currently deployed systems is thatapplications are abstracted from the access technologies and the networks that transport the

14


information from the source to the destination(s). This means that ITS stations applicationsare not limited to the availability and characteristics of a single access technology and net-working protocol stack. Communication management functions make optimal use of all theseresources transparently to the applications.

ISO TC204 WG16, also known as CALM (Communications Access for Land Mobiles) andestablished at ISO in 200, is the birth place of many of the concepts behind the communicationarchitecture before it was harmonized by COMeSafety.

2.1.1 OSI-like layered architecture

As shown on Figure 2.1, the ITS station reference architecture is layered. At the top sitsthe application layer, immediately below the facilities layer (middleware providing a set ofstandard services to the applications), below it the networking and transport layer and at thebottom the access technologies layer (providing the physical communication media).

This ITS station reference architecture differs from conventional OSI layered architecturesby the addition of vertical entities providing cross-layer management (ITS station manage-ment) and security functions (ITS station security) and the new middle layer (ITS facilities)providing common services to the applications (maps, positioning, time stamping, etc). Thenetwork layer itself also comprises a variety of networking protocols, including IPv6 (forInternet-based communications), GeoNetworking of FAST (for roadside-based and vehicle-based communications), a combination of both (IPv6 GeoNetworking) and possibly otherprotocols.

The particular novelty from a design view point, compared to a typical OSI 7-layer ar-chitecture, are the two vertical entities, i.e. the ITS station management entity and the ITSstation security entity performing a number of cross-layer functions. Cross-layer functionsare not new in the literature (ITS no less than other use cases), but it is the first time thisis explicitly shown on architecture diagrams.

The main difference between ETSI and ISO documents lies in the specification of the ITSstation management entity. So far, ISO CALM has concentrated its effort on the cross-layerfunctions to ensure a given communication flow is matched to a particular communicationinterface (CI) according to application needs and current network conditions. ETSI is nottoo much concerned about this issue because the current ETSI work is largely focused on theused of the 802.11p access technology whereas the focus of the ISO work (CALM) has alwaysbeen the simultaneous support of a variety of access technologies.

2.1.2 Types of ITS stations

Historically, the terms On-Board Unit (OBU), Road Side Unit (RSU) and ApplicationUnit (AU) are used in the automotive industry. However, these terms were not definedwith a networking view in mind and have therefore become obsolete in Cooperative ITS. Inaddition, the ITS station reference architecture doesn’t use these terms either because theywere confusing the discussion. This led to the definition of the ITS station (ITS-S) and adistinction of the supported functions according to the type of environment or network whereit is be located. As such, four types of ITS stations are currently defined, as described onFigure 2.3:

• vehicle ITS station (V-ITSS): ITS station located in a vehicle

• roadside ITS station (R-ITSS): ITS station located in the roadside infrastructure

• central ITS station (C-ITSS): ITS station located in the central infrastructure



Figure 2.1: Simplified ITS Station (ITS-S) Reference Architecture

• personal ITS station (P-ITSS): ITS station located in a hand-held device

More ITS station types may be added in the future, if needed (e.g. for buses, trains,emergency vehicles, tramways, bicycles, motorbikes, truck, ...).

2.1.3 ITS stations hosts and routers

The ITS station is defined as a bounded secured managed domain. In the most general casethe functions of an ITS station (ITS-S) are split into a router (ITS-S router) and hosts (ITS-Shost) attached to the ITS-S router via some ITS station internal network. The router andhosts functions may also be merged into a single entity.

2.1.4 ITS stations and IPv6

In most cases, an ITS station will be linked to other ITS stations and networked entities viaIPv6, either a legacy IPv6 network or a proprietary IPv6 network. In some very specific caseslike for instance direct communication between neighbor vehicle ITS stations using 802.11p,IPv6 may be replaced by some ITS-specific networking protocol like GeoNetworking or alegacy cellular network. Considering the different types of ITS stations shown on Figure 2.3,the following ITS-S IPv6 nodes could exist:

• In the vehicle ITS station, the nodes executing the ITS-S router functions are the ITS-SIPv6 vehicle routers (VRs). The ITS-S host functions may be implemented by the ITS-S IPv6 router, or by ITS-S IPv6 hosts. Vehicle ITS-S IPv6 routers and hosts are alsoknown as mobile routers (MRs) and mobile network nodes (MNNs) when continuousInternet connectivity is supported.

• In the roadside ITS station, the nodes executing the ITS-S router functions are theITS-S IPv6 roadside routers (RRs) and the ITS-S IPv6 border routers (BRs). RoadsideITS-S IPv6 routers are also known as the ITS-S IPv6 access router (AR) when theyprovide access to ITS-S IPv6 mobile router (MR). border routers (BRs) are the ITS-S



Figure 2.2: Detailed ITS Station (ITS-S) Reference Architecture

IPv6 routers connecting the ITS station to the Internet or other ITS stations. TheITS-S host functions may be implemented by an ITS-S IPv6 router, or by ITS-S IPv6hosts.

• In the central ITS station, the nodes executing the ITS-S router functions are the ITS-S IPv6 border routers (BRs) connecting the ITS station to the Internet or other ITSstations and the ITS-S home agents (HAs) for supporting IPv6 mobility. The ITS-Shost functions may be implemented by an ITS-S IPv6 router, or by ITS-S IPv6 hosts.

In this document, the terms On-Board Unit (OBU), Road Side Unit (RSU) and Applica-tion Unit (AU) are meant for IPv6 mobile router (MR), IPv6 access router (AR) and IPv6node, respectively.



Figure 2.3: Types of ITS stations

2.2 ITS station networking and transport

As shown on Figure 2.2, the horizontal ITS station networking & transport layer (SNT) cansupport a variety of networking protocols. Currently, IPv6 Networking and the newly de-veloped FNTP protocol (Fast Networking & Transport layer Protocol, previously knownas FAST) are specified at the ISO TC204 level, respectively in ISO 21210 [ISO-21210]and [ISO-29281-2], whereas GeoNetworking (media-dependent [ETSI-TS-102-636-6-1] andmedia-independent [ETSI-TS-102-636-4-1]) and IPv6 over GeoNetworking adaptation layer[ETSI-TS-102-636-4-2] are specified by ETSI. More networking protocols could be added ifneeded.

The terms Mobility Extensions indicated in the IPv6 + Mobility Extensions box of theSNT is misleading as these are extensions of IPv6 only needed for mobile ITS stations suchas vehicle or personal ITS stations. This is a detail that should not appear on this figuredescribing the architecture of a generic ITS station.

2.3 ITS station management

The vertical ITS station management entity (SME) is in charge of all cross-layers functionsincluding path selection based on pre-set policies, regulations, static and dynamic capabilitiesof the different access technologies. The SME is responsible for the selection of the best com-munication path (communication interface and end-node) according to the flow requirementsexpressed by the ITS station applications, the access technologies characteristics and thecurrent network conditions. The ITS station management entity must thus interact with the



horizontal layers in order to make this determination and more particularly with the ITS sta-tion networking & transport layer (SNT) that must update its forwarding tables according torules provided by the SME. This is illustrated on Figure 2.4 [ETSI-EN-302-665, ISO-24102-1].

Figure 2.4: ITS station communication management

To exploit the availability of multiple access technologies, the SME supports differenttypes of handover, including:

• those involving a change of the point of attachment to the network without a changeof access technology;

• those involving a change of the point of attachment to the network with a change ofaccess technology;

• those involving reconfiguration or change of the network employed to provide connec-tivity; and

• those involving both a change of the point of attachment to the network and networkreconfiguration.

The SME functions are under specification by ISO TC204 WG16 [ISO-24102]. NewISO work items have been launched and published ISO standards are under revision. Inaddition, ETSI TC ITS has also opened work items related to cross-layer functions and theITS station management, in order to comply with the ITS standardization mandate M/453from the European Commission. Existing ETSI work items include Cross-layer architecture[ETSI-TS-102-723-1], MI interface [ETSI-TS-102-723-3], MN interface [ETSI-TS-102-723-4].These work items should actually simply refer to the existing ISO TC204 standards, otherwiseISO and ETSI standards would diverge.

The interactions between the ITS station management entity and the horizontal layers isperformed via Service Access Points (SAPs) (see Section 2.8).



2.4 ITS station security

The vertical ITS station security entity provides common security functionalities to all thehorizontal layers and maintains security credentials used by these [ETSI-TS-102-731]. TheITS station security entity does not perform any particular security mechanism or proto-col. Protocol dedicated security mechanisms and security protocols are implemented at eachlayer. For instance, IPv6 dedicated security mechanisms and protocols, which are subjectto modifications or replacement, shall be implemented at the IPv6 protocol block, not atthe ITS station security entity [Lee2011b, Lee2012a]. This provides more modularity andminimizes development complexity of the ITS station security entity.

The common security functionalities provided by the ITS station security entity include:

• Firewall and intrusion detection management;

• Authentication, authorization, and profile management; and

• Identity, cryptographic key, and certificate management.

Security credentials such as cryptographic keys, authorization tickets, and certificates arestored and maintained at the security entity with other security related parameters and statusinformation. Upon request from horizontal layers, atomic security operations are providedby the security entity. The atomic security operations include:

• Arbitrary bit generation (for the pseudonym service);

• Hashing;

• Signing and verification; and

• Encryption and decryption.

The interactions between the ITS station security entity and the horizontal layers isperformed via Service Access Points (SAPs) (see Section 2.8).

2.5 ITS station access technologies

A variety of access technologies can be used for the communication with other ITS stations,with ITS station internal network nodes, and other legacy ITS nodes. These access tech-nologies can be used simultaneously, and vary according to the type of ITS station and itspurpose. In order to support any given access technology, a new standard must specifyingthe parameters and functions so that the access technology could be recognized by the ITSstation. Currently, the support of several wireless access technologies (infrared [ISO-21214],microwave [ISO-21215], millimeter wave, 2G/3G [ISO-21212, ISO-21213]) and wired accesstechnologies (Ethernet) is already specified, in either ISO or ETSI standards. More accesstechnologies could be supported in the future, without any impact on the other layers of theITS station reference architecture. It is of course not required for a given deployment to im-plement neither all these access technologies nor to implement the specific functions requiredto support all these access technologies. So, the purpose of the standard is to specify how agiven access technology, if needed, can be integrated into the ITS station.



2.6 ITS station facilities

The ITS station facilities is an intermediate layer between the ITS station networking &transport layer (SNT) and the applications, offering them access to information collected byother ITS stations (vehicles, roadside) and freeing them from the necessary message signal-ing to transmit and process data exchanged between ITS stations in a broadcast fashion.The immediate benefit is the sharing of data between various application which would oth-erwise have broadcast potentially similar information, therefore increasing consumption ofnetwork resources and processing power. The current facilities include CAM (Co-operativeAwareness Messages) [ETSI-TS-102-637-2] 1-hop broadcast messages transmitted in the im-mediate vicinity mainly for time-critical road safety purposes, and Decentralized Environ-mental Notification Messages (DENM) (Decentralized Environmental Notification Messages)[ETSI-TS-102-637-3] multi-hop broadcast messages transmitted in a given geographical area.Information collected by CAM and DENM are recorded in a Local Dynamic Map (LDM)[ETSI-TR-102-863] together with other information.

2.7 ITS station applications

As shown on Figure 2.2, applications supported by the ITS station reference architecture aregenerally spread in three categories:

• Road safety: this category comprises all applications that are designed to renderroad traffic safer. These include both applications such as emergency braking or lanedeparture notification which require short range time-critical for immediate actions fromthe vehicles, and longer-range applications such as road hazard events (black ice, vehiclein the wrong direction, road work which require non time critical communications(short, medium and long range).

• Traffic efficiency: this category comprises all applications that are designed to im-prove road traffic. These include road itinerary planning, green wave, road diversion,and require constant exchange of informations between vehicles, the roadside infras-tructure and some traffic information servers.

• Other applications: These are not necessarily ITS-specific applications, but mustbe supported in other to provide a better transportation experience to the road users.They thus include comfort and infotainment applications. This category is also oftenreferred to as value added applications.

These applications rely partly on services offered by the ITS station facilities layer. As aresult of the messages processed by the ITS station facilities, applications may for exampledisplay messages on the navigation system in the vehicle.

These applications may also issue messages to other ITS stations without subsequentlyinvolving the ITS station facilities. For example, as a result of receiving a service notificationby the ITS station facilities, of a charging spot for electric vehicle charging spot, the applica-tion may directly contact a server to enquire about the availability of the charging spot andbook it. In addition, some ITS station applications may be completely standalone, i.e. nottaking benefit of the ITS station facilities at all.



All applications have specific communication requirements1. These application require-ments must be provided to the ITS station management entity in order to determine thecapability of the ITS station to transmit the information and to determine the communica-tion path (e.g. the access technologies) that should be used to route the packets given therequirements provided by the application.

2.8 ITS station service access points (SAP)

The functional blocks of the ITS station communication architecture are interconnected viaService Access Points (SAPs) as presented in Figure 2.2.

SAP Description

Man

agem

ent MI SAP allowing the interaction between the ITS station

management entity (SME) and the ITS station accesstechnologies layer (SAT)

MN SAP allowing the interaction between the ITS stationmanagement entity (SME) and the ITS stationnetworking & transport layer (SNT)

MF SAP allowing the interaction between the ITS stationmanagement entity (SME) and the ITS station facilitieslayer (SF)

MA SAP allowing the interaction between the ITS stationmanagement entity (SME) and the ITS stationapplications

Secu

rity SI SAP allowing the interaction between the ITS station

security entity (SSE) and the IITS station accesstechnologies layer (SAT)

SN SAP allowing the interaction between the ITS stationsecurity entity (SSE) and the ITS station networking &transport layer (SNT)

SF SAP allowing the interaction between the ITS stationsecurity entity (SSE) and the ITS station facilitieslayer (SF)

SA SAP allowing the interaction between the ITS stationsecurity entity (SSE) and the ITS station applications

Betweenlayers IN SAP allowing the interaction between the ITS station

access technologies and the ITS station networking &transport layer (SNT)

NF SAP allowing the interaction between the ITS stationnetworking & transport layer (SNT) and the ITS stationfacilities layer (SF)

FA SAP allowing the interaction between the ITS stationfacilities layer (SF) and the ITS station applications

Figure 2.5: ITS Station Service Access Points (SAP)1To be clearer, all application have specific communication flow requirements as there could be various

flows with different flow characteristics, for instance a voice flow and a video flow when considering a video-conferencing application



According to the ISO specifications [ISO-24102-1], the following types of services, illus-trated in Figure 2.6 must be used for the MN-SAP:

• MN-COMMAND: Sending a command to the ITS station networking & transport layer(SNT) , using the following primitives:

– MN-COMMAND.request: this management service primitive allows the ITS sta-tion management entity (SME) to trigger an action at the ITS station networking& transport layer (SNT), using the following function parameters:

– MN-COMMAND.confirm: this management service primitive reports the result ofa previous MN-COMMAND.request.

• MN-REQUEST: Receiving a request (command) from the ITS station networking &transport layer (SNT), using the following primitives:

– MN-REQUEST.request: this management service primitive allows the ITS sta-tion networking & transport layer (SNT) to trigger an action at the ITS stationmanagement entity (SME).

– MN-REQUEST.confirm: this management service primitive reports the result ofa previous MN-REQUEST.request.

Figure 2.6: MN-Command and MN-Request service primitive

ISO 24102 [ISO-24102-1] indicates that both MN-COMMAND and MN-REQUEST sup-ports up to 256 possible SAP functions. For MN-COMMAND five functions are currenrlydefined; for MN-REQUEST, seven functions are currently defined. This is described in Table2.8:

MN-COMMAND Number Description0 Reserved for future use.1 to 5 Used6 to 224 Reserved for future use.225 For private non-standardized use

Figure 2.7: MN-COMMAND Description



MN-REQUEST Number Description0 Reserved for future use.1 to 7 Used8 to 224 Reserved for future use.225 For private non-standardized use

Figure 2.8: MN-REQUEST Description


CHAPTER 3

ITS station IPv6 networking design

In this chapter, we analyze the IPv6 protocol block of the ITS station networking & transportlayer as it is presently specified by International Organization for Standardization (ISO) inISO 21210 [ISO-21210]. Section 3.1 presents the current content of ISO 21210, whereasSection 3.2.1 discusses what IPv6 features are missing in ISO 21210. Following the designgoals set up in ITSSv6 Deliverable D2.1 Preliminary System Recommendations, we proposeto organize the IPv6 protocol block and the necessary cross-layer functions of the ITS stationmanagement entity into a new set of modules. These are briefly introduced; details of eachmodule are provided into the forthcoming chapters.

3.1 IPv6 networking in the ITS station architecture: ISO 21210

ISO 21210 (CALM: IPv6 Networking) [ISO-21210] is the result of the work performed withinISO TC204 WG16 (CALM). It specifies IPv6 network protocols and services necessary tosupport global reachability of ITS stations (in the context of the ITS station architecture),continuous Internet connectivity for ITS stations and the handover functionality required tomaintain such connectivity. This functionality also allows legacy devices to effectively usean ITS station as an access router to connect to the Internet. Essentially, this specificationdescribes how IPv6 is configured to support fixed and mobile ITS stations (vehicle, roadsideand central ITs stations) and their attached nodes. ISO 21210 doesn’t define a new protocol,a new exchange of messages at the IPv6 layer, or new data structures. It defines how standardIETF protocols are combined so that ITS stations can communicate with one another usingthe IPv6 family of protocols. Currently, ISO 21210 supports the following features:

• IPv6 signaling All the basic set of IPv6 features necessary to establish communicationwith peer IPv6 nodes: Neighbor discovery [rfc4861], Internet Control Message Protocol(ICMPv6) [rfc4443]

• IPv6 addressing Each station is provided with an IPv6 prefix, allowing it to dis-tribute its functions into multiple nodes. The prefix is allocated statically. StatelessAddress Auto-Configuration (SLAAC) [rfc4862] is used to configure the IPv6 addressesof the ITS station nodes attached to the ITS station routers (ITS station internal IPv6interface). For mobile ITS stations, transient addresses are configured as a result ofhandovers (on the ITS station external IPv6 interface).

25


• IPv6 reachability and session continuity NEMO Basic Support [rfc3963] is used tomaintain IPv6 reachability at a permanent address and to maintain IPv6 connectivitywhen a mobile ITS station is moving between IPv6 points of attachment or is changingits access technology.1

• IPv6 mobile edge multihoming Multiple Care-of Addresses Registration (MCoA)[rfc5648] is used in combination with NEMO Basic Support to maintain an IPv6 pathover multiple access technologies simultaneously, in a mobility scenario where the endpoint of the IPv6 communication path is renewed each time the mobile ITS station getsattached to a new access router.

The features provided by the IPv6 protocol block as specified in ISO 21210 are groupedinto modules, as illustrated on Fig. 3.1. This separation into modules makes the specificationof IPv6 functions for each type of ITS station much easier as not all features (thus all modules)are necessarily in all ITS station types.

Figure 3.1: IPv6 functional modules in ISO 21210

The operation of the IPv6 features could be different for distinct types of IPv6 nodes,according to the role they play and the specification of the feature (e.g. the mobility featuresis provided by NEMO, and NEMO behaves differently for the MR and the HA). ISO 21210specifies which modules must be supported for each type ITS station IPv6 nodes i.e. for MR,AR, BR, HA and hosts and rely on IETF RFC specifications (possibly other standards) forthe definition of their operation. Those modules are:

• IPv6 forwarding module This module comprises basic IPv6 features (Neighbor Dis-covery, Stateless Address Auto-Configuration, etc) to acquire necessary IP parameters

1NEMO Basic Support is used instead of Mobile IPv6 to comply with the requirement that and ITSstation, in the most general case is made of several nodes



(IPv6 addressing) and IP next hop determination (IPv6 forwarding). It enables IPv6to run over different lower layer technologies. It must be present in all ITS station IPv6nodes.

• IPv6 mobility management module This modules comprises mechanisms for main-taining IPv6 global addressing, Internet reachability, session connectivity and media-independent handovers (handover between different media) for in-vehicle networks.Nothing new, this module combines NEMO Basic Support [rfc3963] and Multiple Care-of Address Registration [rfc5648]. It must only be present in ITS station IPv6 nodesperforming functions to maintain Internet reachability and session continuity (MR andHA)

• External IPv6 interface module This module comprises the mechanisms necessaryto transmit IPv6 packets back and forth between the IPv6 layer in the underlying accesstechnologies through the IN-SAP. This module performs the IPv6 address configura-tion and reports to the ITS station management entity the status of the IPv6 addressconfiguration, through the MN-SAP. There is one instance of such a module for eachaccess technology used to connect the ITS station to other ITS stations or legacy IPv6nodes.

• ITS station IPv6 LAN interface module This module comprises the mechanismsnecessary to transmit IPv6 packets back and forth between the IPv6 layer in the under-lying access technologies (e.g. Ethernet) through the IN-SAP. This module performsthe IPv6 address configuration and reports to the ITS station management entity thestatus of the IPv6 address configuration, through the MN-SAP. This module must bepresent in all IPv6 nodes of a given ITS station when the ITS station functions aredistributed into separated IPv6 nodes, ITS station IPv6 nodes are linked through anITS station internal network, referred to as the IPv6 LAN in ISO 21210.

• IPv6 security security The need for a module in charge of securing IPv6 communi-cations is acknowledged in ISO 21210, but the required features are not yet defined.

3.2 IPv6 networking issues in the ITS station standards

3.2.1 IPv6 networking issues

The IPv6 Networking protocol block currently specified in [ISO-21210] is defined mostly formaintaining Internet connectivity and session continuity. This presents some limitations asexplained in the following sections. Some of the missing features described below have indeedbeen proposed by the GeoNet European Project (see [GeoNet-D1.2]) , some of which havebeen detailed, whereas some others were left out for future work:

• Inefficient routing between ITS stations As it is specified in [ISO-21210], Internetconnectivity and session continuity for a vehicle ITS station are provided by NEMOBasic Support [rfc3963] (see Section ??). NEMO Basic Support maintains a tunnelbetween a vehicular router (i.e. mobile router or MR) in the vehicle ITS station and acentral router (i.e. home agent or HA) in a central ITS station. As a result of the use ofNEMO Basic Support, all data packets emitted to or from the vehicle ITS station haveto be routed through the HA. Due to this, routing can become extremely inefficient.Routing is clearly inefficient in communication scenarios where a vehicle ITS stationcommunicates with another nearby ITS station (vehicle or roadside), particularly when



the two neighbors ITS stations are on the same IPv6 wireless link, i.e., one IPv6 hopaway. It is even more inefficient for communication between two neighbor vehicle ITSstations which are registered with distinct HA (e.g. in the situation where the twocars are registered in distinct countries or are from distinct car makers). In this case,packets would go through two topologically distant HAs, and may be sent twice on thesame wireless link if the same media is used to access the Internet. In other wordspacket transmission performance is inefficient in some communication scenarios due tothe tunnel established by the NEMO Basic Support protocol. However, this tunnel isnecessary to maintain Internet connectivity and reachability, so we need to provide amechanism that allows direct routing between two adjacent ITS stations in addition tomaintaining Internet connectivity and reachability.

• IPv6 GeoNetworking The GeoNet project has defined procedures allowing the trans-mission of IPv6 packets over a virtual IPv6 link established over multiple ITS sta-tions (vehicle-to-vehicle or vehicle-to-roadside). Multi-hop routing is performed by theGeoNetworking protocol, which is another protocol block of the ITS station networking& transport layer, standardized at ETSI based on the output of the GeoNet project.Combining IPv6 and GeoNetworking requires an adaptation layer between IPv6 andGeoNetworking and is not yet integrated into ISO 21210.

• IPv6 security Although the need to secure IPv6 communications is acknowledged inISO 21210, no mechanisms are provided to authenticate IPv6 signaling.

• Relation with other layers (SAP functions and parameters) The ITS stationmanagement and ITS station networking & transport layer must exchange some infor-mation so that the management entity can determine the best communication path fora given flow and provide routing policies to the IPv6 networking protocol block. Toachieve these goals, the SAP between ITS station management and ITS station net-working & transport layer (MN-SAP) must be defined. Currently, ISO 21210 looselydefines clauses where the IPv6 protocol block reports the status of IPv6 links to the ITSstation management, and where the ITS station management requires the IPv6 net-working protocol block to perform some actions. Regarding the interaction between theITS station management and the ITS station networking & transport layer, the IPv6networking protocol block is not yet specified in any ITS station standard. Currentlythe specification of the relation between the ITS station management entity and theITS station networking and transport layer in [ISO-24102] is limited to the FAST net-working protocol. However, ISO 24102 is under revision, so the necessary mechanismsare now being added.

• Policy routing Routing policies should be specified in a more modular way. Currently,there is no way to handle traffic from some applications in a specific way. Peculiarly, theISO 21210 standard does not provide means to handle a given flow to a specific route.Moreover, the network must be given the ability to perform short term adaptations tosome network event (interface down, new flow, ...), without waiting for the managementto transmit a new decision. Means are required for , on one hand a way to associatepackets to a flow identifier, and on another hand specify per-flow routing policies.

• Seamless IPv6 horizontal handovers No mechanisms are defined in ISO 21210to perform horizontal handovers with minimum packet loss and transparently to theapplications deployed in ITS stations. Specific support functions are required to shortenthe period of time necessary to divert the flow on a new communication path from one



access router to another access router from the same operator and using the same accesstechnology. A protocol such as FMIPv6 [? ] may be deployed in the IPv6 access routersproviding access to vehicle ITS stations.

• Seamless IPv6 vertical handovers No mechanisms are defined in ISO 21210 toperform vertical handovers with minimum packet loss and transparently to the applica-tions deployed in ITS stations. Seamless handovers can effectively be performed usingmobile edge multihoming features (such as MCoA) implemented in the ’ITS-S IPv6mobile router’ and the ’ITS-S IPv6 home agent’. However, specific support functionsare required to shorten the period of time to divert flows from one medium or oneoperator to another.

• IPv6 multicasting No mechanisms are defined in ISO 21210 to support IPv6 multi-casting, i.e. mechanisms to advertised IPv6 multicast groups, to manage group mem-bership and to perform multicast routing, within the ITS station and between ITSstations.

• Dynamic IPv6 address provisioning No mechanisms are defined in ISO 21210 todescribe how the IPv6 prefix to be deployed in the ITS-S LAN is provided to the ITSStation. This delegation must take into account requirements for the stability of thedelegated prefix across re-initialization of the ’ITS-S IPv6 mobile router’. This stabilitymay be required by application or for accounting at the operator side. The stability ofthe delegation may also be considered if the ITS Station migrates from an ’ITS-S IPv6home agent’ to another, for operational reasons or for network optimization consideringthe location of the station.

• IPv4-IPv6 interoperability support While all ITS sub-systems required to supportIPv6 for TCP/IP-based communications, IPv6 nodes deployed in an ITS station mayneed to communicate with existing IPv4-only legacy ITS services or non-ITS servicesthat will continue to operate in the Internet for some years. In addition, as the IPv4address depletion is driving a continuous but slow shift to IPv6 connectivity, someaccess networks will still provide IPv4-only connectivity to the ITS station. The needfor IPv4-IPv6 interoperability features is acknowledged in ISO 21210, but the requiredfeatures are not yet defined.

• Personal ITS station Currently this specification considers only the vehicle ITSstation, the roadside ITS station and the central ITS station. However, vehicle, roadsideand central ITS stations may communicate with personal ITS station. In addition,vehicle users may bring nomadic devices (i.e. personal ITS station) in their vehicle.Such devices may be authorized to configure an IPv6 address and to benefit from on-board Internet connectivity provided by the ’ITS-S IPv6 mobile router serving themobile ITS-S IPv6 LAN’. IPv6 networking for the personal ITS station is not yetconsidered and shall probably be defined in coordination with ISO TC204 WG17. Ata minimum, IPv6 networking for the personal ITS station would have to comply withthe IPv6 features to be supported by all ITS stations as indicated in [ISO-21210].

• IPv6 priority management Currently, no mechanisms are defined to ensure that timecritical or safety-related IPv6 flows or packets are transmitted with higher priority thanother IPv6 flows or packets.

Once [ISO-21210] is open for revision, it is planned to specify the requested IPv6 featuresbased on the ability of the ITS station to be mobile or fixed rather than on the role played



(vehicle, roadside, central or personal ITS station). The rationale is that the roadside ITSstation may be deployed in vehicles e.g. emergency vehicles and that vehicle ITS station maybe parked and act as a roadside ITS station e.g. road operator patrol vehicle parked on theemergency lane in case of accident or traffic jams.

3.2.2 ITS station architecture issues

Although IPv6 networking operations can in most cases be performed independently fromthe ITS station management and other layers, it is necessary, in order to determine the mostappropriate path for a given flow, that the IPv6 protocol block interact with the ITS stationmanagement. In addition, it must also interact with the ITS station security entities in orderto secure IPv6 communications. There is thus a number of issues that must be addressed inother ITS station standard not strictly related to IPv6. These are:

• Application flow requirements There is currently no means to determine how aflow should be treated across the ITS station stack. This first requires to determinerequirements to be applied to each type of flow. There is a variety of requirements andthese include the priority, user preferences (costs, location privacy), technical character-istics (maximum acceptable end-to-end delay), regulations, security level, capabilities(geographic distribution, continuous Internet connectivity, ...). Means to provide theseapplication flow requirements to the ITS station management entity must thus be de-fined .

• Cross-layer flow management The IPv6 protocol block must be able to take deci-sions applying to a set of packets with the same traffic pattern (i.e. flows of packetsgoing from the same set of source and destination nodes for the same application).This first requires to be able to identify flows across the entire ITS station stack, andto apply policies in a coherent manner, i.e. a flow which is given priority at the IPv6layer must be given the same priority at other layers.

• Cross-layer path management In order to select the best available IPv6 path, itis necessary to obtain information about the access technologies characteristics andapplication flow requirements and to monitor the current conditions of the network.All this information cannot be obtained directly by the IP layer, but the informationis available at other layers of the ITS station stack. All these information must begathered in order to decide which routing policy should be applied to a given flow at agiven time.

• Cross-layer security management Atomic security operations such as arbitrarybit generation, hashing, signing/verification, and encryption/decryption should be per-formed in the ITS station security entity when such operations are requested fromthe horizontal layers (or more specifically security modules at each layer/protocol). Inaddition, the interactions between the ITS station security entity and the horizontallayers should be performed in a security mechanism/protocol agnostic way so that thebehavior of the ITS station security entity does not depend on any particular type ofsecurity mechanism or protocol. This would provide more modularity and minimizedevelopment complexity of the ITS station security entity [Lee2011b, Lee2012a].

• Networking protocol block agnostic MN-SAP The ITS station management en-tity and the ITS station networking & transport layer can exchange parameters throughthe MN-SAP. In order to support multiple ITS station networking & transport protocol



blocks (IPv6, GeoNetworking, FNTP, ...), the MN-SAP must be defined agnostically toa particular ITS station networking & transport protocol block. The ITS station man-agement entity must be aware about the features that are supported by all ITS stationnetworking & transport protocol blocks but not how the features are performed. Wetherefore propose to redefine the MN-SAP so that it include the necessary proceduresand parameters, in an abstract way, agnostic to any specific ITS station networking& transport protocol block. For instance, the ITS station management entity doesn’tneed to know what is the structure of an IPv6 address and what it is used for (i.e aHome Address is used as an identifier and a Care-of Address is used as a locator), itjust need to know how each node is identified (node identifier) and where it is locatedin the topology (locator identifier).

• Distributed ITS station functions Networking capabilities such a IPv6 allow todistribute the functions of the ITS station in various ITS station nodes. However, thisis not always considered in the ITS station standards. For instance, a mechanism isnecessary to synchronize the decision taken by the ITS station management betweenmultiple ITS station nodes when an ITS station comprises several ITS station routers.As another example, there is no mechanism allowing ITS station applications deployedin ITS station hosts to provide their flow requirements to the ITS station router.

3.3 IPv6 protocol block design

IPv6 networking as specified in ISO 21210 presents some limitations, as discussed in Section3.2.1. The new needed features do not necessarily fit into one of the modules already definedin the existing ISO 21210 standard, so new modules are proposed, and existing modules areextended, whenever necessary. In addition, the relation between the IPv6 protocol block andthe ITS station management entity was not well defined; we propose that a single modulebe in charge of this relation as it simplifies the relation between modules and removes theirdependency with other ITS station standards.

From our internal investigation, we concluded that the following modules are needed inthe IPv6 protocol block:

• IPv6 adaptation agent module The ITS station architecture comprises a verticalmanagement entity performing cross-layer functions, including functions to determinethe most appropriate communication path for a given flow. It performs the interactionbetween the ITS station management entity and the IPv6 protocol block via the MN-SAP. We therefore propose a new module IPv6 Adaptation Agent in charge of theprocessing of the MN-REQUEST actions sent by the IPv6 protocol block to the ITSstation management entity and the MN-COMMAND actions sent from the ITS stationmanagement entity to the IPv6 protocol block. This includes the notification to theITS station management entity of the status of IPv6 address configuration and thenotification from the ITS station management entity of new policy rules to apply toIPv6 flows. This module is detailed in the Chapter 5.

• IPv6 traffic classifier module This module analyses incoming IPv6 packets andassociate them to a flow identifier. This flow identifier changes the behavior of the wholeIPv6 network stack, enabling IPv6 network modules to perform per-flow operations.This module is detailed in the Chapter 6.

• IPv6 forwarding module This module comprises basic IPv6 features (Neighbor Dis-covery, Stateless Address Auto-Configuration, etc) to acquire necessary IP parameters



(IPv6 addressing) and to perform IP next hop determination (IPv6 forwarding). Itforwards packets to the appropriate interface (internal or external), to upper layers(NA-SAP) or consume them internally. This module is detailed in the Chapter 7.

• IPv6 mobility support module This module performs the functions allowing ITSstation to maintain continuous Internet connectivity and reachability simultaneouslyover multiple access technologies, session connectivity and media-independent han-dovers, in situations where the ITS station is composed of multiple ITS station hostsand routers. It comprises features such Network Mobility (NEMO) Basic Support andMultiple Care-of Addresses Registration (MCoA) and is detailed in Chapter 8.

• IPv6 adhoc networking module This module performs the functions required at theIPv6 layer for direct communications between all IPv6 nodes attached to neighboringITS stations (particularly vehicle ITS stations and roadside ITS stations). It also allowsthe vehicle ITS station to determine whether a roadside ITS station can be used or notto access the Internet. It comprises INPD, a new protocol specifically designed forCooperative ITS and is detailed in Chapter 9.

• IPv6 over GeoNetworking module This module comprises features to combine IPv6networking together with GeoNetworking (IPv6 GeoNetworking). It is executed on anIPv6 external interface with specific characteristics. This module is partly detailed inChapter 10.

• IPv6 security module This module performs the functions required at the IPv6layer to secure IPv6 communications. It interacts with the ITS station security entityvia the SN-SAP and other IPv6 modules. It comprises features such as SeND, IPsec,Shared-key-based authentication, EAP and is detailed in Chapter 11.

• IPv6 multicasting module This module performs the functions required at the IPv6layer for multicast communications, i.e. mechanisms for IPv6 multicast group adver-tisement, IPv6 multicast group membership and IPv6 multicast routing. It comprisesMLD and is partly detailed in Chapter 12.

• IPv4-IPv6 transition module. This module provides backward compatibility withlegacy nodes and access networks not yet deploying IPv6. It comprises DS-MIPv6,L2TP and OpenVPN. [rfc5555] allows IPv6 nodes to configure an IPv6 address whenInternet access is provided by an IPv4 access network. Alternatively, solutions suchas L2TP or OpenVPN may also be used. L2TP builds a PPP connection between thean IPv6 node and an IPv6 access router. This connection is presented to upper layeras a normal PPP network IPv6 interface. Header and data compression may be usedover the PPP link in order to reduce the overhead due to L2TP. This module is partlydetailed in Chapter 13.

• IPv6 router module This module performs the minimum set of IPv6 router functions.It comprises features such as Neighbor Discovery in router mode. This module is notyet detailed in the present document.

• IPv6 host module This module performs the minimum set of IPv6 host functions. tcomprises features such as Neighbor Discovery in host mode. This module is not yetdetailed in the present document.

• IPv6 internal interface module In ISO 21210, this module was named ITS-S IPv6LAN Interface. It is in charge of the configuration, at the IPv6 layer, of the IPv6



interface (e.g. IPv6 addresses), and of executing relevant functions to be executedon the link on which this interface is configured. The internal IPv6 interface is usedfor communication between ITS station nodes composing the same ITS station. Thismodule is not yet detailed in the present document.

• IPv6 external interface module This module is in charge of the configuration, atthe IPv6 layer, of the IPv6 interface (e.g. IPv6 addresses), and of executing relevantfunctions to be executed on the link on which this interface is configured. The externalIPv6 interface is used for communications with a node not belonging to the same ITSstation (i.e. to other ITS station nodes, or to legacy IPv6 nodes). This module is notyet detailed in the present document.

3.4 ITS station management entity design

The ITS station architecture proposes a vertical management entity performing cross-layerfunctions. Cross layer functions are essential for the determination for the best communica-tion interface and next hop (path) since such a wise selection can only be performed once themedia characteristics, the application flow requirements and the current network conditionsare known. In this respect, ITS station management standards also present some limitations,given the limitations of ISO 21210 discussed in Section 3.2.1 and the need for new modulesdiscussed in Section 3.3

The following modules are needed in the ITS station management entity:

• Path Management This new module monitors the available access technologies layerand the network layer and determines a determines available communication paths.This module is partly detailed in Chapter 4.

• Flow Management This new module determines what are the best communicationpaths for a given flow and provides routing policies to the network layer. Each flow isidentified by a flow identifier, that is used across the entire ITS station stack. Require-ments are applied to each flow. This module is partly detailed in Chapter 4.

• Policy Exchange Routing policies highly depends on choices of the vendor, construc-tor, maintainer. This may imply contradictory policies on each ITS Station node. Flowsmay be routed in an asymmetric way, leading for some kind of applications to misbe-have, or for some security or safety requirements to be broken. To prevent such cases,a mechanism for exchanging routing policies is necessary between ITS Station Nodes.This mechanism must exchange all information needed to ensure flow consistency.

• MN-SAP The interaction between the ITS station management entity and the IPv6protocol block must be performed via the MN-SAP, in a network protocol agnosticway so that the behavior of the management entity does not depend on any particularnetwork protocol. Procedures needed to exchange information between the ITS stationmanagement and the ITS station networking & transport layer are defined in ISO 24102and need to be extended in order to include the new procedures and parameters neces-sary for path management, flow management and policy exchanges. This is detailed inChapter 14.



3.5 Open Issues

All the features highlighted in Chapter 3 have not yet been defined or fully defined. Otherlimitations have also been identified and will be investigated, and the architecture designedwill be brushed up if needed. Open issues includes:

• Asymmetric path selection;

• Multiple routers: the ITS station may be connected to the outside word through mul-tiple ITS-S routers, for instance via a router providing 11p and 11n, and a nomadicdevice providing 3G connectivity;

• Security and Privacy (use of pseudonyms);

• Multicast: distribution of information to multiple nodes;

• GeoMulticast: distribution of information to multiple nodes located in a given geo-graphical area (GeoArea).

Readers are invited to follow the progress of the ITSSv6 project and to refer to deliverableD2.4 Final System Specification to be published in February 2014.


CHAPTER 4

Path and flow management

In this chapter, we describe procedures within the ITS station management entity (SME) todetermine what are possible communication paths and to determine which flow should berouted to which communication path. The SME collects information from all the horizon-tal layers and gathers it into several databases. It then determines what are the availablepaths and issues routing policies to be applied to communication flows. These policies aretransferred to the ITS station networking & transport layer (SNT).

4.1 Terminology

This section provides definitions for path and flow in the context of the ITS station referencearchitecture for Cooperative Intelligent Transportation Systems (C-ITS). These are veryimportant to understand the remaining parts of this document. Paths and flows are definedfrom the view point of an individual ITS station i.e. different ITS stations have a differentview on the available paths and ongoing flows. As a result, path and flow identifiers areunique within an ITS station.

• Path: a path is defined as a sequence of adjoining nodes and links between two con-trollable communication end points, from a starting controllable communicationend point to the furthest controllable communication end point towards a or destina-tion node or a set of destination nodes (See Figure 4.1).The controllable communicationend points from the view point of an ITS station are the next hop and the anchor.The next hop is the first controllable communication end point where the packets areforwarded to on the path whereas the anchor is the furthest controllable end point. Alocator identifies the topological network location of each controllable communicationend point. Another important parameter of the path is the Communication Inter-face (CI) used to reach the next hop. As such, the locator on the local ITS station’sside identifies the topological location in the network where the CI is attached to whileon the central ITS station side it identifies the topological location of the anchor.

• Flow type: a flow type is defined as:

– a set of requirements (QoS, security, operational) and priority

35


Local routing domain Controllable

ITS Station

other nodesN

A

E

Rol

es o

f ITS

-S

Next hop

Anchor

End Point

Communication Interface

EE

N

N

N

A

ALocator(s) are allocated to each CI

E

The Paths from this ITS-S point of view

Figure 4.1: Definition of path in the ITS station architecture

– of the same communication type (Unicast, GeoCast, MultiCast, AnyCast, Bicast)

Flow types could be preassigned, well known and registered at some authority or definedby the applications following a number of conventions.

• Flow: a flow is defined as an identifiable sequence of packets

– of a given flow type

– to be transmitted to the same peer entity or set of entities

Each flow is assigned a unique FlowID (unique in the ITS station) and is mapped to agiven path or a set of available paths

4.2 Overview

The procedures to determine what are the possible communication paths and to determinewhich flow should be routed to which communication path are divided into distinct functionswithin the SME:

• Path management is the process of obtaining various information about the con-trollable end points where packets will have to be routed and keeping track of all thecandidate and available paths. This information is obtained from horizontal layersusing MN-Request.STAGeoNot, MN-Request.STATopoNot, MN-Request.STAServNot,MN-Request.PathNot, MN-Request.PathMetricNot for the information coming from theSNT. If not provided by the SNT, the path status could also be estimated inter-nally from collected statistics. In the other direction, the SME informs the SNT usingMN-Commmand.PathMNGT and MN-Commmand.STAServDiscov. This function isdetailed in Section 4.3;

• Flow management is the process of keeping track of the requirements applying toall application flows and collecting flow statistics. The requirement are obtained fromthe application or facilities layers using MF-Request.ITS-S-Appl-Reg while statisticsare obtained from the SNT using MN-Request.FlowStat. On the other direction, flowstatistics are requested by the SME to the SNT using MN-Command.FlowFeedback ;



• Path selection is the process of determining the most appropriate path(s) from all thecandidate paths for a given application flow or a set of flows of the same characteristics.The decisions are commanded to the SNT using MN-Command.FlowClassificationRuleand MN-Command.FlowPolicy ;

These functions require information from various layers. The SME collects informationand monitors the current state of the network (via the MN-SAP), the characteristics ofthe access technologies (via the MI-SAP), flow requirements expressed by applications (viathe MA-SAP) or the facilities (via the MF-SAP), and other information maintained locallyin order to determine routing policies to be applied to application flows, given the flowrequirements, the current status of the network and access technologies characteristics. Thisis illustrated on Figure 4.2. The collected information is recorded in various tables:

ITS StationApplication

Management Facilities

Network & Transport

Access

DENM LDMCAM

GeoNetworking

802.11p

Application Requirement

Path / Flow Management

Decisionmodule

Wifi 3G

Position

IPNEMO

Routing

IPFilter

NDPMN-SAP

GeoIP-SAP

Strong focus Consideration of parameters

ITS Local Network

Other Protocols

SAM

Figure 4.2: Overview of the relation between SME and other entities

• The local ITS station information table is defined for keeping track of the status ofthe local ITS station while the neighbor ITS station information table is definedfor maintaining the status of the other ITS stations that are involved in thepath determination (i.e MR, AR, CN, etc). This latter table will thus not recordinformation about all ITS stations in the neighborhood of the ITS station. Detailsabout these tables are presented in Sections 4.6 and 4.7;

• The path information table: records various information about all existing or pos-sible paths. Details about the table are presented in Section 4.8.

• The flow requirement table records performance requirements to be applied to eachapplication flow; the flow information table records networking parameters used to



identify each flow; the flow statistics table records various statistics about each flowand how flows are classified and routed by the SNT; the flow policy table recordspolicies generated by the SME. The last table allows to link flows to paths. Detailsabout these tables are presented in Sections 4.9, 4.10, 4.11 and 4.12.

VCI ID

Path Informationtable

Neighbor ITS-S Information

table

Flow Policy table

Flow Information table

Flow requirement table

Local ITS-S Information

table

VCI listVCI ID and VCI list are

defined in [ISO-24102-1]

Path ID

Flow ID

Flow Type ID

Application ID

Flow Statistics table

Node ID

Management Parameter

Identifier

Link between ID and database

Figure 4.3: Relation between management parameters and identifiers

Figure 4.3 shows the relation between these tables and the main layer from where theinformation is obtained. Figure 4.4 shows the information flow between the path selectionmanager in the SME and the horizontal layers. The functions offered by the SME to managepaths and flows (path management, flow management, path selection) are described in theforthcoming sections, followed by the description of all the tables.



Flow

Flow req & Flow stat

Network &Transport

Management



table

Network &Transport

Facilities

AccessMI-REQUEST

MF-REQUEST

MN-COMMAND

MN-REQUEST

ITS-S information

Path Information

Information

MI-SAP

MF-SAP

MN-SAPGeographic Position

Topological Information

Path Status

Interface

Flow requirement list

ITS-S Basic info

SAP

MN-SAP

Path Infomation

Flow Classification Rule

Network Metric

ITS-S Information

Service

STATopoNot

STAGeoNot

PathNot

Event

PathMNG

FlowClassRule

ITS-S-Appl-Reg

PathMetricNot

STAServDiscov

STAServNot

Path and Flow Management

MI-SAP

MF-SAP

MN-SAP

SAP Function parameter

MF-SAPMN-

SAP

[ISO_24102]

Flow StatisticsFlowStatNot

[ISO_24102]

Flow PolicyFlowPolicy

FlowMonitor Flow Statistics


table

Flow Policy table

Flow statistics table



Figure 4.4: Cross-layer information flow for path and flow management



4.3 Path management

Collected information maintained in the SME is recorded into various tables. In total, all thecollected information is divided into seven tables, that could be further divided into threecategories, i.e. information about ITS stations, information about paths and informationabout flows.

The process of path management starts from the perception of network elements in thenetwork where the ITS station connects. First, as can be seen in the Figure 4.5, the infor-mation of the self ITS station is recorded in the local ITS station information table. Andthen, when the ITS station connects to a network, the ITS station finds the neighbor ITSstation with some exchange of messages (neighbor discovery mechanism). Obtained informa-tion about the neighbor ITS stations (e.g. topological, geographical and service information)is notified to the management entity of the ITS station and stored in the neighbor ITS sta-tion information table. Among the neighbor ITS stations, some of them may provide the“access" service to the other network. The service information is also recorded in a field inthe corresponding neighbor ITS station information table entry. The ITS station may dis-cover neighbor ITS stations that provide anchor service with signaling of some network layerprotocols between the ITS stations.

Controllable ITS Station

other nodesN

A

E

Rol

es o

f ITS

-S

Next hop

Anchor

End Point

Communication Interface

S

A1N1

N2

N3

A2

D1

Local ITS-S info table SNeighbor ITS-S info table D1, D2, N1, N2, N3, A1, A2

Path info table N1 A1 D1

N2 A1 D1

N3 A1 D1

N2 A2 D1

N3 D2etc.

Management Parameters

D2

Direct pathOptimized path

Anchored pathVCI1

VCI2

VCI1

N1 A2 D1VCI2

Figure 4.5: Controllable communication points

Path can be calculated from the neighbor ITS station information table, selecting theparameters of the CI, the topological locator, the next hop and the anchors. We refer as theanchored path the path via at least one anchor that does not provide any route optimizationservice (typically to the Internet) as illustrated in Figure 4.5. In contrary, the optimizedpath is a more direct path for reaching a given destination (an anchor may not be needed forthe optimized path). On the other hand, a more direct path that does not go beyond the localrouting domain is called a direct path. Thus a direct path does not contain any next hopnor any anchor (except for containing an ITS station which have access service without usingthe service.) In vehicle ITS station situation, the packet via the direct path is often forwardedby intermediate vehicle ITS stations using a multi-hop Vehicular Ad-hoc Network (VANET)routing protocol without depending on any infrastructure (neither roadside infrastructure



nor Internet infrastructure).The candidate paths can be calculated from the neighbor ITS station information table,

selecting the parameters of the CI, the topological locator, the next hop and the anchors. Inmany situations there are multiple paths reaching to a given destination node, using differentaccess technologies, different access networks (roadside access network, public access network,cellular operator network), and passing through different administrative domains (e.g. urbanWiFi operators C and D). Packets sent over different paths to the same destination nodeexperiment different characteristics (delay, throughput, security level, etc.). And eventually,the SME receives the notification from the network layer protocols that a path is establishedand became ready-to-use (Available path). All the information about candidate paths andthe available paths is recorded in the path information table. All the paths are identified bya unique identifier called Path ID.

In summary, the path information table provides the most up-to-date status of the pathsby the notification of the network layer. For intelligent path selection, it is also importantto predict the candidate path and its characteristics. The prediction can be performedwith, for example, the help of statistical analysis, cross-layer information, information fromsensors, etc. SME must thus maintain the following two types of path information so thatthe path selection manager takes a decision based on both the most up-to-date status andthe prediction:

• Available path: Path that is established and ready-to-use.

• Candidate path: Path that is theoretically possible but not ready-to-use.

How to calculate the candidate path intelligently and how to allocate the Path ID to eachpath depend on path management mechanism and out of focus of this document.

Vehicle ITS Station

Router Host

RouterHost

Vehicle ITS Station

Router

Router

Mobile operatorBase Station

Roadside

Vehicle

Router

Anchor

VANET

Internet

wifi

3G

11p

Locator

Anchored path

Optimized path

Direct path

Figure 4.6: Possible paths between two vehicle ITS stations



The SME should be aware about the surrounding ITS stations (nodes) in order to com-prehend the status of the network around it. Especially, the SME should be aware aboutthe services provided by each neighbor (e.g. vehicle ITS station able to relay information toother vehicles, roadside ITS station providing Internet connectivity, etc.) This is essential fordetermining the appropriate path where to route the packets. This information is referredto as the ITS station information and is recorded in two separate tables, the local ITSstation information table and the neighbor ITS station information table.

In addition, it is also important to comprehend the network status. The SME stores inthe path information table information about all the possible paths. In order to selectthe best path, the SME must first have the most up-to-date view of all the available paths.Keeping track of the available paths requires to gather information from several layers andto maintain accurate information. All these parameters are very important to determinewhat path and how long a path may be available. They are stored in the following tables:

• Local ITS station information table: records various information about the localITS station. Details about the table are presented in Section 4.6. This table is updatedwhenMN-Request.STAGeoNot,MN-Request.STATopoNot,MN-Request.STAServNot arereceived by the SNT. Other information could be obtained by the ITS station facilitiesbut is not currently defined.

• Neighbor ITS station information table: records various information collectedfrom neighbors ITS stations. Details about the table are presented in Section 4.7.This table is updated when MN-Request.STAGeoNot, MN-Request.STATopoNot, MN-Request.STAServNot are received by the SNT. Other information could be obtainedby the ITS station facilities but is not currently defined.

• Path information table: records various information about all existing or possiblepaths. Details about the table are presented in Section 4.8. This table is updated whenMN-Request.PathNot or MN-Request.PathMetricNot are received by the SNT.

Since multiple protocol blocks could in some situation provide the same functions (e.g.GeoNetworking and IPv6 are both independent network layer protocols), parameters obtainedthrough the M*-SAP are expressed at the SME in a protocol agnostic fashion (e.g. an IPaddress is provided by the IPv6 layer to the SME as a locator and an identifier). In addition,these parameters are also generalized as there are multiple possible configurations of an ITSstation, and ITS stations are of different types. The SME treats all ITS stations the sameway.

4.4 Flow management

4.4.1 Flow requirements

In order to determine on which path a given flow should be routed, the SME must firstknow which path satisfies the network performance requirements for that flow. For legacyapplications, information about new flows should be provided by the ITS station networking& transport layer. For applications complying with the ITS station reference architecture(i.e. ITS station applications), flow requirements must be provided from the applications tothe SME. This would require new mechanisms or modification of existing mechanisms in theITS station set of standards, particularly in the situation where the ITS station functionsare distributed in several hosts and routers. This applies to both applications residing at theITS station application layer and applications residing at the ITS station facilities layer:



• From a flow management view point, ITS station facilities processing broadcast mes-sages e.g. DENM, Co-operative Awareness Messages (CAM), SAM are indeed con-sidered as applications. CAM [ETSI-TS-102-637-2], DENM [ETSI-TS-102-637-3] andSAM [ISO-24102-4] must thus provide their flow requirements to the ITS station man-agement entity. This would be done via the MF-SAP.

• While some applications residing at the ITS station application layer are fully relyingon the data received via CAM, DENM and SAM messages, some other applications -ITS specific or not - may need to initiate their own message exchanges. These mustalso provide their flow requirements to the ITS station management entity. This wouldbe done via the MA-SAP.

Basically, the same parameters would have to be exchanged via the MA-SAP and MF-SAP. A flow requirement table is then needed to record performance and other types ofrequirements to be applied to each application flow (note that there could be multiple flowtypes for each application). This table is detailed in Section 4.9 (Table 4.5).

A particular protocol stack may be requested for a given flow, for instance, some stakehold-ers may prefer a specific protocol stack (e.g. BTP/GeoNetworking/11p) when it is availablewhile IPv6 would only be used otherwise. Other may avoid a specific media.

4.4.2 Flow registration

Entries in the database are identified by a flow ID unique to the ITS station. The ITS stationmanagement entity must thus manage the allocation of this flow ID. Some application flows,in particular the ones identifying ITS station facilities flows such as CAM, DENM and SAMmay be well-known and thus registered into some central authority with pre-determinedvalues, identified by a flow ID.

4.4.3 Flow statistics

In order to take relevant path selection decisions, the SME needs to have a view on how theyare applied in the SNT. This need is covered by flow statistics. Flow statistics gather thelist of flows that transit through the network, with associated data about their load, and theway they are handled by the SNT.

Statistics are provided for any registered or not registered flow. The SNT reports themdepending on its matching capabilities. For both not registered and registered flows, itmay report flows at a higher level of details than specified in a previously received MN-Command.FlowClassificationRule. By this means, the decision algorithm may refine its out-put for already defined flows.

Foreach flow, three type of data are retrieved:

• Network statistics: actual statistics about number of packets and throughput of theconsidered flow.

• Classification information: informs the SME how the flow is actually handled. It in-forms to which Flow Identifier (FlowID) the flow was mapped, and to which PathIdentifier (PathID) the flow is currently routed.

• Matching information: matching information that exactly identify the reported flow.This data may be reused as-is by the SME in a MN-Command.FlowClassificationRule.



The SME regularly probe the SNT for updated statistics. These statistics are storedin the flow statistics table. Then, they are used by the path selection process to adjustnetwork load.

4.5 Path selection

4.5.1 Flows mapped to paths

Selecting a path is essentially the process of matching a given flow to a path according toapplication flow requirements and the current characteristics of all the available paths. Thepath selection can be made based on the information stored in the flow requirement table andthe characteristics of the paths stored in the path information table. The decision is takenbased on multiple criteria (e.g. delay, bandwidth or stability). The path selection processmust consider:

• CI: selecting a path is mostly equivalent to selecting a CI since the communicationcharacteristics of a path are mostly determined by the media type of CI including datarate, cost, reliability, security, power consumption, etc.

• Next hop: selecting a path depends on the selection of the next hop, because two pathsleading to the same controllable communication end point are different when a CI isconnected to different next hop;

• Type of path: as highlighted on Fig. 4.6, paths could be of very different types. Theanchored path is usually significantly longer, but may also be considered more stableand more secure. Under certain circumstances, paths of a given type may be availablevery briefly while significantly increasing the performance. If flow requirements allow,a flow routed on a path may thus be re-routed onto another path.

• Anchor: multiples anchors may be deployed in topologically distant and geographicallydistributed locations. Selecting the most appropriate one could improve the perform-ance, particularly in terms of delay. However, a given anchor often implies peculiaradministrative and security policies which take precedence over the performance.

In the situation of a vehicle ITS station, the selection of the access router is importantespecially in a VANET environment where multiple ARs may be used to access the Internet.When the AR is reached in a multi hop manner, it is the furthest controllable communicationend point i.e. the anchor; when it is reached directly, it is the first controllable communicationend point, i.e. the next hop. In the situation where the controllable path starts and completesat the same node, anchor and next hop would be the same.

The SME must be able to take such a decision with the most complete knowledge ofnetwork and access technologies status, and application flow requirements. SAPs and infor-mation tables are designed so as the SME gets all necessary information. If so, the SME isable to enforce its decisions to the SNT on a per-flow basis. This principle allows to definepolicies according to the destination ITS station, the source ITS station, the application, orsome identified traffic from an application. To each flow are applied distinct policies.

4.5.2 Flow policies

Flow policies have to be built so that these mostly comply with application flow requirementsand optimize network and hardware resources. Finally, this decision should be made in anenvironment where both ITS station aware and legacy applications evolve.



As a result of performing the path selection, flow policies (rules) are communicated by theSME to the SNT using MN-Command.PathMNGT. These rules are configurable by stake-holders, e.g. users, device vendors, service providers, OEMs, car manufacturers. As such,these rules are competitive factors among stakeholders, so the definitions of these policiesare outside the scope of any International Standard. Default routing procedures could bepre-registered in any manner the manufacturer wishes to implement or could be performedbased on the source and destination of the flow and other parameters. Default settings areparticularly important so that flows originated from legacy applications for which require-ments are not registered by the application with the ITS station management can be routed.Default policies as well as dynamic flow policies are provided to the SNT by the same means.

4.6 Local ITS station information table

The local ITS station information table includes four categories of information. All entriesare uniquely identified by the Station ID, as defined in [ISO-24102]. The station type (e.g.vehicle ITS station, roadside ITS station) is useful information to determine the influenceof the movement of the station on the paths managed by the ITS station, while the vehicletype as defined in [ETSI-TR-102-863] could be useful to qualify the ability of the local ITSstation to relay packets not interned to itself.

The second category is the topological information, currently limited to the locatorwhich indicates the location of the locator ITS station in the network topology. It is animportant information for routing, and is actually used in routing tables (best prefix match).

The third category is the geographic information about the position of the local ITSstation. The geographic information includes geographical position (latitude, longitude andaltitude) and movement information (speed and direction). It is used to compute the distanceto other nodes and by the ITS station networking and transport layer.

The forth category are capabilities which provides a list of the capabilities of the localITS station, like for example, the ability to preserve sessions while changing its point ofattachment, the ability to maintain connectivity simultaneously via multiple CIs, or theability to provide location privacy support.

Some of the Information is maintained internally within the SME, while other couldbe obtained from various layers. The topological and geographical categories are dynamicinformation.



Parameter DescriptionBasic Station ID Identifier of ITS station. Preferably globally unique. See details

in [ISO-24102-1].Station type Type of ITS station. ex) Vehicle ITS-S , Roadside ITS-SVehicle type (Optional) Type of vehicle. ex) car, bus, taxi, motor cycleLatitude WGS-84 latitude of the ITS station expressed in 1/10 micro

degree.Longitude WGS-84 longitude of the ITS station expressed in 1/10 micro

degree.Altitude Altitude of the ITS station expressed in signed units of 1 meter.

Geograp

hic Speed Speed of the ITS station expressed in signed units of 0.01 meter

per second.Heading Heading of the ITS station expressed in unsigned units of 0.1

degrees from North.Accuracy Accuracy indicator of the geographical position of the ITS station

Time stamp The time stamp that the geographic position is recorded.Capabilities The capabilities that the local ITS-S have acquired. ex.) Locator

registration, Session continuity, location privacy support, and etc.

Table 4.1: Local ITS station information table



4.7 Neighbor ITS station information table

Parameter Description

Basic Station ID Identifier of ITS station. Preferably globally unique. See details

in [ISO-24102-1].Station type Type of ITS station. ex) Vehicle ITS-S , Roadside ITS-SVehicle type Type of vehicle. ex) car, bus, taxi, motor cycle

Top

olog

ical Locator Indicates the location of the ITS-S in the network topology. In

the Internet, it is the network part (first 64bits) of an IP addressthat indicates the network topology location of the node.

Scope Topological distance indicator from the local ITS station.• on-link, • Local Network, • Extended Local, • ITS domain, •Global Network, • TBD

Latitude WGS-84 latitude of the ITS station expressed in 1/10 microdegree.

Longitude WGS-84 longitude of the ITS station expressed in 1/10 microdegree.

Altitude Altitude of the ITS station expressed in signed units of 1 meter.

Geograp

hic Speed Speed of the ITS station expressed in signed units of 0.01 meter

per second.Heading Heading of the ITS station expressed in unsigned units of 0.1

degrees from North.Accuracy Accuracy indicator of the geographical position of the ITS station

Time stamp Time at which the geographic position was recorded.Services The services that the ITS-S can provide to self ITS-S . ex) DNS,

Internet access, group membership management.

Table 4.2: Neighbor ITS station information table

The neighbor ITS station information table includes four categories of information, similar tothe local ITS station information table. It could be obtained from various layers. All entriesare uniquely identified by the Station ID, as defined in [ISO-24102]. The station type (e.g.vehicle ITS station, roadside ITS station) is useful information to determine the influence ofthe movement of the station on the paths managed by the ITS station, while the vehicle typeas defined in [ETSI-TR-102-863] could be useful to qualify the capability of a neighbor ITSstation to relay packets not intended to it.

The second category is the topological information, currently limited to the locatorwhich indicates the location of the neighbor ITS station in the network topology. It is animportant information for routing, and is actually used in routing tables (best prefix match).

The third category is the geographic information of neighbor ITS stations and includesgeographical position (latitude, longitude and altitude) and movement information (speedand direction). In addition to the basic geographic information, the SME can obtain moredetailed vehicle status information from the facilities layer, using LDM [ETSI-TR-102-863],CAM [ETSI-TS-102-637-2] and DENM [ETSI-TS-102-637-3]. Also the SME can calculaterelative information like distance to the surrounding ITS stations with its own geographicinformation.

The forth category are services, instead of capabilities recorded in the local ITS stationinformation table. In the network, a service is often provided by neighbor ITS stations; it is



thus logical to bind the service information corresponding to a given ITS station informationentry. Multiple service can be provided by same neighbor ITS station. Examples of servicesmeaningful at the network layer include the ability for e.g. a roadside ITS station to offerInternet connectivity (free or paid), to allow vehicle ITS stations to route relay packets toother vehicle ITS stations, etc. Other services not useful for networking may also be listedhere.

4.8 Path information table

This section describes how the three types of information in the path information (CI infor-mation, path status and path metric) are managed in order to determine candidate paths.The list of the parameters is shown in Table 4.3.



Parameter DescriptionLink ID Unique identifier of a Virtual Communication Interface (VCI)/CI

where the path starts from. See [ISO-24102-2] for details.Media type The kind of a wireless communication interface is used. CIclass(15)

CI Data rate Data rate in the link in units of 100 bit/s (DataRate(5)). And

DataRateNW(6), DataRatesNW(7) and DataRateNWreq(8)Cost Price information. Cost of communication in terms of money: per

byte/per second/flat-rate/free of charge. (Cost (17))Reliability Percentage value indicating estimate of reliability. (Reliability (18))Security Security mechanism used in wireless interface. ex) WEP, WPA

Power Con-sumption

Power consumption of the interface when the interface is transmittingdata and when the interface is receiving data.

Status Status of CI (CIstatus(42)). e.g. 0: not existent 1: existent 4:registered 8: active 16: connected 64: suspended 128: inactive

Path ID Unique Identifier to identify the pathLocator Identifier indicates the topological location of the ITS station in the

network.

PathStatus Next hop ITS station on the path that acts as a border router when packet goes

beyond the network managed by a local routing protocol.Anchor ITS station that provides Locator registration function to the ITS

station .Reachability Topological distance indicator from the CI.

• on-link, • Local Network, • Extended Local, • ITS domain, • GlobalNetwork, • TBD

Capabilities Communication capability of the path.• Reverse reachability for host • Session continuity for network• Session continuity for host • 1-to-n for group • QoS• Reverse reachability for network • 1-to-n for GeoArea • TBD

Status Status of the path.0: not available 2: ready to be used 4: going to up1: being used 3: potentially ready 5: going to down

Payloadsize

Size of payload for a packet using the path.

Metric Delay A trip time that the wireless interface has, and actual round trip time

to reach to the node in the destination scopeHop Number of hops to reach to the destination.

Table 4.3: Path information table

The first category is the CI information. Information about access technologies is no-tified from the access layer to the management entity via the MI-SAP. 52 CI parametersare specified in [? ] as shown in Table 4.4. "I-Parame.No" indicates the identifier of theparameters. It is given as a parameters of the MI-SET and MI-GET command to respectivelyread and write these parameters. The SME can access these parameters at arbitrary timeusing MI-GET, however some parameters are mandatory to be maintained in the manage-ment entity, which is called VCI performance parameter list (VCIperformList) (See detailsin [ISO-24102-1], bold characters in Table 4.4). These are the actual values of performanceparameters’ values of VCIs and the information is kept about all the VCIs in the managemententity.



VCIperformList is also useful to see the path performance. Beside VCIperformList , welist important parameters from access technologies in Table ?? ((Number) after CI parametername indicates M-Param.No in the Table). Media type, data rate, cost and reliability areCI parameters via the MI-SAP. These are important parameters to determine the path.

AuxiliaryChannel, ControlChannel, ServiceChannel, RXsensitivity, TXpower, DataRate,DataRateNW, DataRatesNW, DataRateNWreq, Directivity, BlockLength,MinimumUserPriority, TimeOfLastReception, InactivityTimeLimit, DistancePeer, CIclass,CommRangeRef , Cost, Reliability, Properties, CommProfile, MinimumSuspendPriority,Medium, NWsupport, CIaccessClass, RegulatoryInformation, FreeAirTime, SIMpin,ProviderInfo, MediumUsage, MedUseObservationTime, SuspendSupportFlag,QueueAlarmThreshold, QueueLevel, MACaddress, MACaddrTemp, TimeoutRegister, MedID,VirtualCI, FrameLengthMax, KinematicVectorIn, KinematicVectorOut, CIstatus, Notify,MinPrioCrossCI, CckId, PeerMAC, QueueLowThreshold, PeerRXpower, TXpowMax,ManufacturerDeviceID, Connect

Table 4.4: 52 CI parameters specified in [? ]

The second category is path status that includes the information about the parametersthat characterize the path including the ITS Station information that is in the middle ofthe path (AR, HA, MR and CN), capability of mobility support, topological locator of thestarting point, availability of the path, reachability of the path and etc. Path status isprovided by network parameters that come from MN-SAP. Some paths can be created fromsame CI using different routing protocols, different next hops and anchors. These paths areidentified by path ID. Topological locator indicates the topological location of the node andthe access network where the CI is attached to.

The “reachability” field indicates which part of the network is reachable beyond the neigh-bor ITS station. In principle, just after configuration of a VCI, the VCI cannot reach beyondanywhere before the network layer configurations, except for On-link. As network config-uration progresses, the path completed reachability extended to reach more nodes beyondOn-link. The state is stored in the reachability field as On-link, Local Network, ExtendedLocal, ITS domain and Global Network (Note that the difference is depicted in Figure 4.7).

On-link Reachability to ITS stations that are one hop away from the source ITS station.Typically, it corresponds to ITS stations within the radio range of a wireless interface.In the range, the source ITS station can reach them without any routing protocol.

Local Network Reachability to the ITS stations that are in the network controlled by alocal routing protocol. In vehicle ITS Station case, it is the reachability to the vehicleand roadside ITS Stations in a wireless multihop vehicular ad-hoc network. Somerouting protocols enable multihop communication.

Extended Local Reachability to the ITS station internal nodes of the neighbor ITS stationsin the Local Network. Typically, the ITS station internal nodes attached behind anITS station router in a vehicle or an ITS station router in roadside ITS station do nothave a routing function. A protocol is needed to exchange the station internal prefixin order to reach nodes attached to the neighbor ITS Station.

ITS domain Reachability to central ITS stations that provide ITS services. Depending onthe security policy or administration policy, ITS domain may not provide the reacha-bility to the Global Network.



On-link

Extended Local

Global Network

Local Network

ITS domain

MR

MNN

CN

AR

S

ITS-S Information

- Identifier

- Topological information

- Geographical information

- Service information

Path Information

- Communication Interface

- Path status

- Metric

CN

AR

Wireless

WiredAnchor

Figure 4.7: Network around vehicle ITS station

Global Network Reachability to all the other nodes in the connected network. To en-able global reachability with moving environment, session continuity capability may berequired.

Note that the reachability may not be established in the above order (on-link→Local Net-work→Extended Local→ITS domain→Global Network). Some CI may acquire Global Net-work reachability just after On-link reachability without accessing Local Network (e.g. 3G,WIMAX).

The management entity maintains also “status” in the path information table. The man-agement entity stores the information of all the paths that includes:

Available path: Path that is established and ready-to-use.

Candidate path: Path that is theoretically possible but not ready-to-use. Candidate pathsare calculated in the management entity from the combination of the entries containedin ITS station information table.

“Status” of the paths shows the availability of the path. Status can be either “being used”,“ready to be used”, “potentially ready”, “going up”, “going down”, or “not available” as shownbelow. The lifetime of the path is maintained as the estimated starting time and ending timeof the availability. The lifetime is linked with the status field.

“being used” The path is used. When the path is in this status, the starting time is thehistory records when the path became available and the ending time is the estimatedtime of unavailability.



“ready to be used” The path is ready to be used. When the path is in this status, thestarting time is the history records when the path became available and the endingtime is the estimated time of unavailability.

“potentially ready” The path potentially exists but it is not managed yet. i.e. Pathselection manager is aware of the possibility of the path, however it is not sure the pathcould become available before a trial is performed. When the path is in this status,both the starting time and the ending time are left empty.

“going up” The path is going to be available. When the path is this status, the startingtime is the estimated time of availability and the ending time is the estimated time ofunavailability.

“going down”, The path is going to be unavailable. When the path is in this status, thestarting time is the history records when the path became available and the endingtime is the estimated time of unavailability.

“not available”. The path is unavailable. When the path is in this status, both the startingtime and the ending time are the history records of the last available time.

In all cases, if the estimation is not possible, the estimated time is left as empty.The third category is path metric that is determined by the network layer protocol or

the lower layers. Examples of path metrics are propagation delay, payload size, and numberof hops. To obtain the propagation delay, same measurement is needed. The payload size isoften determined by the underlying technologies. For example, since wireless interfaces havespecific MTU and the network layer protocol blocks have specific size of header encapsulation,the payload size of the path can be often calculated. The number of hops is obtained bymeasurement, or provided by some routing protocol.

We leave room to add other parameters in the path information table for future extension.

4.9 Flow requirement table

The flow requirement table shown in Table 4.5 is proposed to maintain the complete list ofapplication flow requirements. Entries are identified by Flow type ID.

The existing Application requirements list (ApplReqList) defined in [ISO-24102-1] enablethe CI selection but is not sufficient for path selection. The parameters are notified tothe SME using MF-REQUEST “ITS-S-Appl-Req”. Only the following four parameters arespecified as ApplReqList : Data rate, Cost, Network protocol support and Type of CI.



Parameter Description and ExamplesGen

eric Flow Type ID globally registered or locally registered

Application ID unique ID in the ITS-S, Application classes (Non-ITS aware, ITSaware (ITS-AID))

Priority A number that indicates the priority of the flowData rate Minimum average data rate requested at the MI-SAP in 100

bit/s. Corresponds with I-parameter 6.

QoS

Packet loss rate The rate of dropped packets.Stability Indicator how long the path is assumed to last in order to

estimate probability of packet loss due to handover.Delay A trip time that the wireless interface has, and actual round trip

time to reach to the node in the destination scope in milli second.Jitter A measure of the variability over time of the packet latency

across a network.Throughput Required data size delivered to the destination over a unit of

time.APDU size Required maximum size of payload for a packet of the flow

Com

mun

ication mode Required communication mode (ex. unicast, multicast, geocast,

broadcast, anycast)capability Required communication capability (ex. Connection-based /

connection-less, Continuous Internet connectivity)reachability Required reachability (ex. 0: on-link, local network, extended

local, ITS domain, global)Monetary cost Maximum acceptable cost of the link-usage in terms of money.

Corresponds with I-parameter 17.Corresponding module (optional) Corresponding CI type, and Corresponding Network

protocol modulesSecurity services Required security service (2 octets flags)

Table 4.5: Flow requirement table

4.10 Flow information table

The flow information table shown in Table 4.6 is proposed to maintain the complete list ofongoing flows. Entries are identified by the Flow ID and are linked to the flow requirementtable via the Flow type ID. This table is used by the SME when performing path selection.The Destination field permits the management to make a decision that takes routing intoaccount. Particularly, the SME only considers paths which can reach the destination node.

The whole table is transmitted to the SNT for performing traffic classification. Theprotocol-specific information is passed by the application or by the SNT, through MN-Command.FlowStatistics. It is only interpreted by the network layer.



Parameter Description and ExamplesID

s Flow ID Unique identifier for the flowFlow Type ID Requirements for the matching flow

(Traffic Class ID) Classification issued for the matching flow

Protocol-a

gnostic Communication Mode Communication mode used by the matching flow (Node, Group,

or GeoArea)Destination Destination of the matching flow (Node ID, Group ID, or

GeoArea ID)Source Source ITS station Node ID of the matched flow.

Protocol Networking protocol ID of the matched flowProtocol Information Protocol-specific information, provided by applications or

network. It is ignored by management.

Table 4.6: Flow information table

4.11 Flow statistics table

The flow statistics table shown in Table 4.7 is proposed to maintain statistics about ongoingflows. The SME may request these statistics from the SNT. These statistics would providethe SME a picture of the network status and the ability to adjust its own decisions to actualtraffic.

The SNT reports statistics at an arbitrary level of preciseness. It reports one or severalstatistics per Flow ID. Depending on its matching capabilities, the SNT may give a moredetailed view if it detects that several network flows are indeed matched to the same FlowID. This situation can occur if a Flow ID is defined using wildcard parameters, or if a trafficdoes not belong to any Flow ID.

Consequently, the flow information may be reused by the SME to build more specificpolicies for a particular traffic. This way, the SME is able to overload existing flows andpolicies by new ones, without relying on flow registration from applications. It is able tomanage flows issued from legacy applications.

Flow ID and Path ID fields show to the SME how its decisions are applied by the SNT.Datarate and packets per seconds provide actual statistics for each reported flow.



Parameter Description and ExamplesFlow

inform

ation

Communication Mode Communication mode of the reported connection (Node, Group,or GeoArea)

Destination Destination of reported connection (Node ID, Group ID, orGeoArea ID)

Source Source ITS station Node ID of the reported connectionProtocol Network protocol ID of the reported connection

Protocol Information Protocol-specific information, provided by network. It is notcomputed nor used by the management.

IDs Flow ID Flow Identifier currently issued for traffic from this connection

Path ID Path currently used for traffic from this connection

Stats Datarate Datarate of this connection in bits/seconds

Packets per seconds Packets per seconds of this connection

Table 4.7: Flow statistics table

4.12 Flow policy table

The flow policy table shown in Table 4.8 is proposed to maintain policies generated by theSME and transmitted to the SNT. Entries of this table are indexed by a unique pair of FlowID,Path ID (TrafficClass ID,Path ID).

One Flow ID (TrafficClass ID) may be routed to several interfaces, with a given level ofpreference. The priority field is the preference of a policy among others.

Parameter Description and ExamplesFlow ID Unique identifier for the flow

(TrafficClass ID) (Classification of the flow)Path ID Path to use for the flowPriority Priority of this policy

Table 4.8: Flow policy table


CHAPTER 5

Module IPv6 adaptation agent

5.1 Overview

The IPv6 adaptation agent module is in charge of managing the relation between the IPv6networking protocol block and the ITS station management entity (SME) as illustrated inFigure 5.1. This relation is required for path and flow management within the SME in orderto determine what are the available paths, which one is preferred for a given flow, given theapplication flow requirements, network and access technologies characteristics and to providerules to be applied to a given flow at the level of the IPv6 networking protocol block (seeChapter 4).

MN-SAP

IPv6Adaptation

Agent

Decision module

IPv6 Network Protocol Block

ex)Routing, Addressing, NDP, NEMO, INDP

Event

Action

Network & TransportManagement

ex)Path Selection ManagerFlow Selection Manager

MN-REQUEST

MN-COMMAND

Eventnotification

Actionrequest

Figure 5.1: IPv6 Adaptation Agent

Relevant events within the IPv6 network protocol are notified to the IPv6 adaptationagent. The protocol specific parameters in the event notification are translated into theprotocol agnostic parameters and they are sent to SME using MN-REQUEST. The IPv6adaptation agent processes the actions requested by the SME using MN-COMMAND and

56


converts them into actions meaningful at the level of the IPv6 networking protocol block andpasses them to other IPv6 modules.

The procedures and parameters exchanged between the SME and the IPv6 protocol blockare defined in Chapter 14 (MN-SAP). The mapping between the abstract parameters recordedin various tables within the SME and the corresponding parameters used within the IPv6networking protocol block is described in Section 5.3.

The detailed formats of parameters and examples are also shown in the following sections.The management of flows within the IPv6 networking protocol block is described in Section5.5 whereas the management of paths within the IPv6 networking protocol block is describedin Section 5.4. The relation between the IPv6 adaptation agent and other IPv6 modules isoutlined in Section ??.

5.2 Parameters maintained at the network layer

5.2.1 Parameters maintained at the IPv6 layer

5.2.1.1 Locator and identifier

The network topology locator of an ITS station IPv6 node is obtained from the IPv6 addressconfigured on each of its Communication Interfaces (CIs). It corresponds to the first 64 bit ofthe IPv6 address i.e. the network ID part of the address while the last 64 bits form the nodeidentifier and correspond to the CI identifier. As each ITS station node could have differentaddresses (e.g. one for each CI or even multiple per CI if a CI is connected to multiplenetworks at once), each ITS station IPv6 node could have several locators for each CI.

In addition to the locator and the identifier associated to a CI, the entire ITS stationmust be idenfified. The ITS Station Internal Network Prefix (IINP) indicates its position inthe network topology. More precisely, it is the locator of all the ITS station nodes on the CIattached to the ITS station internal network. Considering the entire ITS station, the locatorof the ITS station corresponds to locator of the ITS station router on its CI. Since therecould be multiple CIs and multiple ITS station IPv6 nodes, an ITS station router generallyhas multiple locators.

There is thus a distinction to be made between the network ID of a specific CI that couldvary according to the network where it is attached to (as a result of mobility or networkreconfiguration without moving) and the network ID corresponding to the IINP. The latterindeed plays the role of a unique identifier and can thus be used to identify the ITS stationi.e. the ITS station ID. Though usually configured for a long period of time, this ITS stationID may be changed as a result of network reconfiguration and can only be used as a non-permanent ITS station ID. It can be used for routing, but not as a unique identifier for thelifetime of the equipment.

When mobility support protocols are used to maintain network connectivity, multipleaddresses are configured on the IPv6 external interface(s). The Home Address (HoA) isnormally used to identify the node while the temporary Care-of Address (CoA) is used as toidentify the network where it is currently attached to. In such a situation, the network IDpart of the CoA is the locator of the ITS station IPv6 node on the CI on which this address isconfigured, while the node ID part only identifies the CI. In addition, the network ID part ofthe HoA is the locator of the ITS station IPv6 node when at home. When using NEMO formobility support, the ITS Station Internal Network Prefix (IINP) corresponds to the MobileNetwork Prefix (MNP) and serves both as the ITS station identifier and the locator of alllMNNs, on the interface attached to the ITS station internal prefix.



These topological information are notified, whenever necessary; to the SME using MN-Request.STATopoNot.

5.2.1.2 Service

The service field is a set of flags that indicates the service that could be provided by theneighbor ITS station. The relation can be client and server of some service.

Here, let’s take three examples of services. The “locator registration” service is provided byan HA in NEMO and vehicle ITS Station has the information in HA list in the network layer.The information can be obtained by Dynamic Home Agent Address Discovery (DHAAD)request and DHAAD reply. On the other hand, an AR provides the “access” service inthe IP networks. An ITS station can discover the AR by Router Solicitation (RS), RouterAdvertisement (RA) or Dynamic Host Configuration Protocol (DHCP) messages. The resultsof the messages are often stored as a default gateway in the IP routing table. These servicethat can be provided by the neighboring ITS station are are notified to the SME by MN-Request.STAServNot.

As an ITS station can provide several services, the multiple flags of service field can bemarked at the same time. Since an ITS may provide multiple service, the service informationis recorded with 64bits flags. The other flags are reserved for future usage. The service canbe discovered by the service discovery mechanism located in any layer.

The CI information have big impact to the correspondent path as a starting point of thepath. They are provided from the interface between the management entity and the accesslayer (MI-SAP). i.e. Media type, data rate, reliability and etc (See Section ??).

Path status includes the parameters that characterize the path. In the case of the Internet,the topological locator corresponds to network part (first 64 bits) of the IP address configuredto the CI. Multiple locators can be configured to the CI at the same time and in such case,the path selection manager considers that these are different paths. The topological locatoris stored in the routing table and for example, exchanged by Neighbor Advertisement (NA),Router Advertisement (RA) and DHCP.

In the Internet-based communication, an AR is the “next hop” of the path. The “nexthop” is also maintained in the routing table as a default gateway and can be obtained byRA and DHCP. The next hop is an AR in the case where the correspondent path goes toinfrastructure, and it is an MR in direct V2V communication.

In the NEMO mobility management module,, the “anchor” corresponds to the HA. TheHA address is maintained in the HA list and can be obtained by Dynamic Home AgentAddress Discovery (DHAAD), Binding Update (BU) and Binding Acknowledgement (BA).Anchor field indicates neighbor ITS station provides a location registration service to mobileITS Station to support mobility. The “Next hop” and “anchor” parameters are linked to anentry of the ITS station information table.

The reachability of the path is often determined by the types of the address. In IPv6,link-local address and global address correspond to the “on-link” and “Global Network” reach-ability, respectively. Some reachability information is also maintained in the routing table.For example, the routing entries added by some routing protocol indicate the reachabilityto the network. “Local Network” reachability is enabled by VANET routing protocols (e.g.GeoNetworking). “Extended Local” reachability is obtained by IPv6 Internal Network PrefixDiscovery (INPD) by obtaining the route to the ITS station internal prefix.

For example, as a “capability”, reverse reachability of the path is acquired by the locatorregistration to an anchor. In NEMO, reverse reachability capability is acquired by the messageexchange of BU and BA between HA and MR. The result of the message is stored in Binding



Update List (BUL) in NEMO. QoS, multicast for group and multicast for GeoArea are alsoexamples of the capabilities. The path can have multiple capabilities at the same time, thusthe multiple flags of capabilities can be marked at the same time.

These information about the path are notified to the SME by MN-Request.PathNot.when the event are obtained.

In the metrics field, payload size, propagation delay and number of hops are the para-meters for the path status. Payload size is determined with MTU and header size. Forexample, in the case that the path is established with GeoNetworking, IP and NEMO overWifi interface, the payload size is 1340 Bytes and can be calculated by equation 5.1, whereMTU of wifi interface is 1500 Bytes, header size of GeoNetworking is 80 Bytes, header ofIP is 40 Bytes, and header of NEMO encapsulation is 40 Bytes.

Payload = MTU–GeoNetworking–IP–NEMO (5.1)

To obtain the propagation delay, same measurement is needed, and the number of hopsis obtained by measurement, or provided by some routing protocol.

Path metric information are notified using MN-Request.PathMetricNot.

5.2.2 Parameters maintained at the GeoNetworking layer

Geographic information can be obtained by the GeoNetworking layer., the position (latitude,longitude and altitude), the movement information (speed and heading) of the neighbor ITSstations with the accuracy indicator and the time stamp are maintained in the locationtable. These parameters are exchanged by the beaconing and the location service. Relevantinformation is notified to the SME by MN-Request.STAGeoNot.

5.3 Mapping between management and IP parameters

5.3.1 MN-REQUEST function parameters and corresponding events

Table 5.1 shows the mapping between the MN-REQUEST function parameters (detailed inChapter 14) and the events occuring within the IPv6 network protocol block.

5.3.2 MN-COMMAND function parameters and corresponding actions

Table 5.2 shows the mapping between the MN-COMMAND function parameters (detailed inChapter 14) and the action in the IPv6 network protocol block.

When the path selection module takes a decision to establish a path, the decision isnotified from SME to the IPv6 adaptation agent using MN-Command.PathMNG. Thenthe IPv6 adaptation agent pass the decision as an action request to a network layer module(e.g. NEMO). NEMO reacts based on the action request specifying the parameters of pathestablishment (e.g. CI, topological locator, next hop, anchor and etc).

When all the available path is not appropriate for the ongoing flows, the SME requests anaction for service discovery to the IPv6 adaptation agent usingMN-Command.STAServDiscov.For example, when the ITS station needs the other ITS station that provide “access" service(e.g. AR), it is translated as an action of sending Router Solicitation (RS) in IPv6 protocolblock. ITS station sends location service request for geographic information discovery. In thecase that the ITS station needs more appropriate anchors, it sends Dynamic Home AgentAddress Discovery (DHAAD) request to obtain the list of the HA in NEMO.

MN-Command.FlowPolicy is used for specifying which flow should go to which path.Then the rule is inserted to the IP filter.



MN-REQUEST Protocol Examples of corresponding eventsSTAGeoNot GeoNet

workingReception of the geographic information of a neighboringITS station by beaconing or location service reply

STATopoNot NDP Reception of the topological information of aneighboring ITS station by router advertisement orneighbor advertisement

INPD Reception of the topological information of aneighboring ITS station by INPD advertisement

DHCPv6 Reception of the topological information of aneighboring ITS station by DHCP advertisement

STAServNot NDP Reception of router advertisement from an ITS station.It tells that the ITS station have the service to “access”to the IPv6 Internet

NEMO Reception of a DHAAD reply. It contains the list of theITS station that have the “locator registration” service.

PathNot Addressing

Configuration of a link-local IPv6 address. It means“on-link” reachability is enable from the CI

INDP Reception of INDP advertisement. It gives theinformation about the reachability to “extendedVANET”

NEMO Success of locator registration gives the informationabout a ready-to-use path with reverse reachability isestablished

PathMetricNot NDP Reception of a router advertisement that contain theMTU information

NEMO Establishment of MR-HA tunnel. It reduces 40 bytes ofMTU because of the NEMO header.

Table 5.1: Mapping between Events in IPv6 Network Protocol Block and MN-REQUEST

5.4 IPv6 path management

5.4.1 Procedure

Figure 5.2 shows how path selection is performed from the moment that a CI becomes avail-able. Numbers on the arrows indicates the message between the SME and the data plane.The numbers from (1) to (4) show the message via MI-SAP, and the numbers from (5) to(13) show the interaction via MN-SAP. The procedure progresses basically from bottom totop in the ITS station reference architecture.

[ISO-21218, ISO-24102-2] describe the initial part of the procedure and message exchangevia MI-SAP.

(0) A CI’s power is turned on

(1) The Interface Management Entity (IME) registers the CI identified by an unique iden-tifier, and the Communication Interface Management Adaptation Entity (CIMAE) no-tifies the event to the SME using RegReq.

(2) IME may perform “Cross-CI prioritization” as an optional procedure to synchronizetransmission of multiple CIs based on user priority. The event is notified from CIMAE



MN-COMMAND Protocol Examples of corresponding actionsPathMNG Address

ingConfiguring a new CoA

NEMO Establishing MR-HA tunnel sending BU from aselected CoA to a selected HA address

STAServDiscov NDP Sending a router solicitation to discover ITS stationthat have the “access” service allowing to connect tothe IPv6 Internet

GeoNetworking

Sending a location service request to discover thegeographic information of an ITS station

NEMO Sending a DHAAD request message to discover the listof ITS Station that provides the “locator registration”service

FlowPolicy IP Filter Configuring the IP Filter for a flow to a selected path

Table 5.2: Mapping between Actions in IPv6 Network Protocol Block and MN-COMMAND

to the SME using PrioReg.

(3) A TX-VCI and an RX-VCI shall be created by the CIMAE based upon the default MIB.Parameter 42 "CIstatus" shall be set to "active". The event is notified from the CIMAEto the SME using Events.req(E21218-3).

(4) Once VCIs are created, the SME can send MI-COMMAND to the corresponding VCI.For example, Wakeup starts repetitive transmission of wake-up signal with maximuminterval in milliseconds. Monitor requests monitoring of CI parameters.

Some of the messages exchanged via MN-SAP from (5) to (13) are defined in Section 14.3 inthe thesis and others are defined in [ISO-24102-2].

(5a) If GeoNetworking is disabled, the SME can activate GeoNetworking by setting GeoEn-ableStatus (N-Parameter) using MN-SET. If GeoNetworking is already running orGeoNetworking is not used, this step is skipped. N-Parameters for GeoNetworkingare specified in Appendix 14.2.4.

(5b) In the case where GeoNetworking is used over the created VCIs, the VCIs is set asGeoAccessInterfaceIndex in N-Parameter for GeoNetworking using MN-SET.

(6) When GeoNetworking is enabled, there are three ways to obtain the geographic inform-ation of neighbor ITS Station: beaconing, location service and packet reception. EveryGeoNetworking packet has a common header that includes source nodes’s geographicinformation. The information is notified to the SME using STAGeoNot . Note that, ifGeoNetworking is not used, geographic information of neighbor ITS stations cannot beobtained from the network layer.

(7) The IPv6 Link-local address on an egress interface (VCIs or GeoNetworking interface)is configured. PathNot notifies that on-link “reachability” is enabled from the egressinterface. Topological locator field is left as empty, because network part of link-localaddress (fe80 ) does not indicates the topological location.

(8a) On reception of a Router Advertisement from a roadside ITS station, the system re-ceives the topological locator information of the roadside ITS station. The information



Management Network & Transport

GeoNetworking

IP

Acess

CI Management Adaptation Entity

(a)Interface

Initialization

(b)Interface

Configuration

(c)Network

environment perception

(d)Path Selection

Interface RegistrationInterface Prioritization

VCI creation (TX-VCI / RX-VCI )

NDP

MNPP

Mobility protocol

Beaconing Location ServicePacket reception

Link-local address configuration

N-Parameter

RA reception

ITS-S prefix discovery

Anchor DiscoveryLocator registration

VCI

(0) Interface Power on(1)

(2)(3)

(4)

(5a), (5b)

(6)

(8a), (8b), (8c)

(10)

(11a), (11b)(12a), (12b)

(4) WakeUp.req, Monitor.req and etc.

(1) RegReq.req(2) PrioReg.req(3) Events.req(E21218-3)

(7) PathNot.req

(5b) MN-SET (GeoAccessInterfaceIndex)(5a) MN-SET (GeoEnableStatus)

(6) STAGeoNot.req

(8c) PathMetricNot.req(8b) STAServNot.req(8a) STATopoNot.req

(9) PathNot.req

(10) STATopoNot.req

(11b) STAServNot.req(11a) STAServDiscov.req

(12b) PathNot.req(12a) PathMNG.req

(7)

Global address configuration(9)

Figure 5.2: Procedure of Path Management

is sent to the SME using STATopoNot. Note that the system may receive geographicinformation of the station at the same time, when the Router Advertisement is encap-sulated into GeoNetworking packet. See step (6) for this case.

(8b) At the same time on the reception of the Router Advertisement, the system also detectsthat the neighbor ITS station provides a access service. The service capability of theITS station is notified to the SME using STAServNot.

(8c) The Router Advertisement may contain the MTU size of the access network as a RouterAdvertisement option. In this case, the MTU size is notified to the SME using Path-MetricNot.

(9) A Global address is configured on the received egress interface on the reception of aRouter Advertisement. The SME notifies the acquisition of Global Network “reachabil-ity” from the egress interface with the topological locator which is the 64 bits networkpart of the acquired global address using PathNot.

(10) Eventually, an IPv6 Internal Network Prefix Discovery (INPD) advertisement is re-ceived. From the message, the IPv6 obtains a new CoA (i.e. topological locator) andITS station internal IPv6 network prefix of the neighbor ITS station (i.e. the neighbor



ITS station ID). The information of the neighbor ITS station is notified to the SMEusing STATopoNot.

(11a) Once a global address is configured on an egress interface, it has to be registered toan anchor to support mobility. When there is no available anchor recorded in the ITSstation information table, the SME can request service discovery of anchor service tothe mobility management module using STAServDiscov.

(11b) As a result of anchor service discovery (In NEMO case, DHAAD is the service dis-covery), the mobility management module obtains a list of anchors. The anchor list issent to the SME using STAServNot.

(12a) The SME requests IP to registers the topological locator with an anchor based onthe path selection decision using PathMNG. The CI selection, address selection, accessrouter selection and anchor selection are reflected as a result of the MN-COMMAND.

(12b) The status of locator registration (e.g. Binding Acknowledgement or Binding Error)is notified from the mobility management module to the SME using PathNot. Fromthe MN-REQUEST, the SME updates the path information kept in the SME.

Although the SME performs (a) CI initialization and (b) CI configuration, it manages thecycle of (c) network environment perception and (d) path selection at the same time.

5.5 IPv6 flow management

Flow management enables to specify per-flow operations. It means that network componentsare able to work on class of packets (flows) rather than globally. The base of the systemis the ’IPv6 Traffic Identifier’ module whose role is to classify IPv6 packets according totheir networking parameters (source and destination ITS station Nodes, application, type ofservice, ...). Modules may use this classification among the network entity (IPv6 Forwardingmodule, IPv6 Security module).

The Flow Identifier (FlowID) field is used as a key in the network entity. Some MN-Command messages, such as MN-Command.FlowPolicy use a Flow Identifier (FlowID)field. Decisions provided in these messages are only applied on IPv6 packets whose classific-ation is the same as the given Flow Identifier (FlowID).

The classification is determined at the moment the IPv6 packet enters the network entity.It sticks to the packet all along it stays in the network entity.

5.5.1 Architecture

Figure 5.3 shows how the per-flow framework operates in the IPv6 networking architecture.The Flow Identifier (FlowID) field is a reference defined by the management entity to link

MN-Command.FlowClassificationRule with various messages such as MN-Command.FlowPolicy.The Adaptation Agent is responsible for maintaining this link in the IPv6 network block.

5.5.2 Feedback and update

The SME has to ajusts its policies to the actual network traffic. It is even more true for makingcohabit flows that comes from CALM-aware and legacy applications. Statistics about eachflow, either registered or not, permits the SME to make new policies that change the pathof some flows to optimize network resources without breaking application requirements. The



Figure 5.3: Routing architecture of the IPv6 networking stack.

SME may even use these informations to power on or off a CI, in order to fine-tune energyconsumption.

Figure 5.4 describe messages between the SME and the network entity to manage flows.

(13) The SME regularly performs a lookup on flow statistics. The lookup is triggered by aFlowFeedback.request.

(14) Upon reception of this MN-Command, the network entity has to transfer all flow stat-istics to the SME using the FlowStatistics request.

(15) Once the whole table has been sent, the network entity confirms completion by con-firming the initial command. The FlowFeedback.confirm message is sent to the SME toconclude communication.

(16) The SME computes new decisions for adjusting network resources usages. It sends itsactual decision on existing or new flows. It provides it by sending FlowPolicy messages.

(17) The SME also sends FlowClassificationRule messages for newly defined FlowID. Thesemessages reuse data contained in FlowStatistics messages. Peculiarly, the protocol-specific data field, not interpreted by the SME, is provided as-is in FlowClassification-Rule messages.

When performing its decisions, the SME takes into account application requirements.These requirements, that are provided from CALM-aware applications, may imply new de-




IP

(e)Feedbackgathering

(f)Flow Selection

Flow Statistics

Policy enforcement

Flow enforcementTraffic enforcement

(16)(17)

(15) FlowFeedback.cfm(14) FlowStatistic.req(13) FlowFeedback.req

(17) FlowClassificationRule.req(16) FlowPolicy.req

(13)

(15)(14)

Figure 5.4: Procedure of feedback and flow management.

cisions to be taken. These are commited to the network entity in the same way as previouslyshown.


CHAPTER 6

Module IPv6 traffic classifier

6.1 Overview

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to allow an ITS station to map incoming IPv6 traffic to a FlowID. This isensured by the IPv6 traffic classifier module within the IPv6 protocol block. The IPv6 trafficclassifier module is in charge of mapping incoming IPv6 packet to a FlowID identifying asequence of packets of a similar pattern, e.g. all traffic originated from a given source, or alltraffic intended to a given destination port, or a particular connection between two nodes, orall traffic corresponding to a given priority, etc.

This classification is made based on ’Flow classification rules’ provided by the SME to theIPv6 network block through the MN-SAP. These rules are translated by the ’IPv6 AdaptationAgent module’ to parameters meaningful within the IPv6 networking protocol block. The’IPv6 Traffic Identifier module’ tries to match each incoming IPv6 packet against "Flowclassification rules". It maps each IPv6 packet to a FlowID or doesn’t classifies it if no rulematches. FlowID is not unique, several flows may be mapped to the same FlowID.

6.2 Relation between IPv6 networking modules

Traffic classification is performed on IPv6 packets received from ’IPv6 internal interface(s)’,’IPv6 external interface(s)’ or the layer above through the NF-SAP. When receiving an IPv6packet, the ’IPv6 Traffic Identifier module’ operates first so as other module be able to useits classification. The classification of the IPv6 packet sticks to the packet when it evolves inthe IPv6 networking stack.

Each IPv6 networking module that uses per-flow rules selects the appropriate rule ac-cording to the FlowID mapped to the IPv6 packet. If a particular rule exists for this FlowID,the module executes a specific processing. If no specific rule exists for this FlowID, or ifexisting rules does not succeed to apply, the module uses its default rules. The null FlowIDis reserved for default rules.

66


6.3 IPv6 packets classification

The ’IPv6 Traffic Identifier’ module classifies IPv6 packets according to informations pro-vided in MN-Command.FlowClassificationRule. Protocol-specific information (ports, mes-sage types, ...) contain the following information:

• IPv6 Flow label

• Transport protocol number

• Transport-specific informations (ports, message numbers, spi, etc)

Matching is performed against information available in IPv6 packets. Considered datais all data from the IPv6 header (IPv6 source, IPv6 destination, IPv6 flow label, IPv6 nextheader, ...) and from the transport header (source port, destination port, message type,message code, ...). Matching is performed from the most specific rule to the least specific.When a null parameter occurs in the MN-Command.FlowClassificationRule or in protocol-specific information field, it is considered as a wildcard parameter. For IPv6 addresses, aprefix may be provided instead of an address.

Specificity of rules follow these principles:

• If the IPv6 Flow label is provided, the rule is more specific

• The more the destination IPv6 prefix is specific, the more a rule is specific

• The more the source IPv6 prefix is specific, the more a rule is specific

• If the destination transport port is provided, the rule is more specific

• If the source transport port is provided, the rule is more specific

6.4 Feedback

In order to be able to adapt its decision to the actual traffic, the management entity needsto have some statistics about how its decisions are applied. Moreover, it has to know whatis the effective amount of traffic generated by each flow, either it is declared or not. Thepurpose of the MN-Command.FlowFeedback and MN-Request.FlowStatistics messages is toprovide to the management entity the most accurate picture of the network.

Whenever the ’IPv6 Traffic Identifier’ module receives a MN-Command.FlowFeedbackmessage, it has to retrieve statistics and provide it to the management entity. The ’IPv6Traffic Identifier’ module sends statistics using the MN-Request.FlowStatistics message.

Feedback is returned by the ’IPv6 Traffic Identifier’ module in a per-connection basis. Themeaning of a connection depends on its transport protocol. For connection-based protocols,connections are considered as defined by the protocol specification. For datagram-based pro-tocols based on source and destination ports, connections are identified using a 4-tuple (sourceaddress, destination address, source port, destination port). For datagram-based protocolsbased on messages, connections are identified using a 3-tuple (source address, destinationaddress, message id).

For each connection, the ’IPv6 Traffic Identifier’ module identify the Flow Identifier(FlowID) issued for the last packet of the connection and the Path Identifier (PathID) towhich the last packet of this connection was routed. Additionnally, it reports the number ofpackets per seconds and the datarate of this connection.



6.5 Policy Exchange

The Policy exchange mechanism exchanges Flow Classification rules and Flow Policies be-tween several ITS Station nodes. Whenever two ITS Station nodes has several possiblepaths, a symmetric enforcement is needed on both sides of a L3link. This enforcement aimsto avoid asymmetric routing situations. Such situations may lead application requirementsto be broken on the return path of the flow.

On reception of a MN-COMMAND.FlowClassificationRule or a MN-COMMAND.FlowPolicy,the policy exchange module states if an update is needed to a particular Neighbor ITS Stationnode. In such case, the new policies are exchanged to the Neighbor ITS Station node.

Policies are translated and filtered before being sent to the Neighbor ITS Station node:

• The logic of Flow Classification rules shall be reversed for matching incoming trafficrather than outgoing traffic

• The logic of the pathID (sources and destinations) shall be reversed

• Policies must be filtered to keep only the pathID to which the policy exchange messageis sent. If several pathIDs match the same ITS Station Node, policies may be mergedin the same message.

• Policies not marked for export shall not be sent

Policies received by the ’IPv6 Policy exchange module’ shall be handled the same wayas ’Flow policies’ transmitted through the ’MN-SAP’. In case of contradicting policies, localpolicies shall be preferred. When receiving policies, they shall be translated into ’Flowpolicies’ and reported to the management through the ’MN-SAP’.


CHAPTER 7

Module IPv6 forwarding

7.1 Overview

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to allow IPv6 packet forwarding. This is ensured by the IPv6 forwarding modulewithin the IPv6 protocol block. The IPv6 forwarding module comprises basic IPv6 features(Neighbor Discovery, Stateless Address Auto-Configuration, etc) to acquire necessary IP pa-rameters (IPv6 addressing) and IP next hop determination (IPv6 forwarding). It enablesIPv6 to run over different lower layer technologies. It allows IPv6 packets to be sent to thenext IP hop through the selected IPv6 link. It passes the packets to either:

• the NF-SAP if the destination IPv6 address belongs to the receiving node;

• to the relevant IPv6 External Interface module if the next hop to the destination IPv6address belongs to the ITS station itself;

• to the relevant IPv6 Internal Station Interface module if the next hop to the destinationIPv6 address doesn’t belong to the ITS station itself;

• to the relevant IPv6 protocol block module if the packet contains no payload (IPv6layer signaling).

As a result of the notification to the ITS station management entity (SME) of a changein the IPv6 address by the ’external IPv6 interface’ module or a tunnel set-up from the IP’mobility management’ module, the SME should notify new forwarding table entries to the’IPv6 forwarding’ module.

The IPv6 Forwarding module exchanges packets with the above layer if the IPv6 sourceor destination address in the packet belongs to the ITS-S IPv6 node. According to theITS station design (ISO 21217 Figure 14), traditional OSI network and transport layers aremerged into a single layer. No transport layer function specific to CALM are needed. Shouldthere be any, their specification is out of scope of this International Standard. However, inprinciple, the packets should be transmitted to some transport layer function before they aretransmitted trough the NF interface.

69


7.2 Flow policies

The SME provides routing policies on a per-flow basis. Flows are classified by the ’IPv6 TrafficIdentifier’ module, this classification is used by the ’IPv6 Forwarding’ module to apply theappropriate routing policy.

7.2.1 Management

Flow policies are managed (e.g. added, modified, deleted) by the MN-Command.FlowPolicymessage. They contain pairs of (FlowID, PathID) that form a unique key. The FlowPol-icy.action defines the action to perform on flow policies.

Valid actions are:

• ’add’, add a flow policy with the given parameters

• ’modify’, modify the priority of a given (FlowID, PathID) pair

• ’delete’, delete a given (FlowID, PathID)

• ’flush’, flush all flow policies with a given FlowID

Moreover, when a PathID is deleted from the IPv6 network block, associated policies areflushed by the IPv6 Forwarding Agent.

Note: If the ’IPv6 Traffic Identifier’ module is not present on a node, only flow policies thatcontain a null FlowPolicy.FlowID are considered by the ’IPv6 Forwarding’ module. Otherflow policies are ignored.

7.2.2 Algorithm

Flow policies are matched using the FlowPolicy.FlowID field, and ordered using the Flow-Policy.priority field. The ’IPv6 Forwarding’ module use the following algorithm to determinethe PathID.

If the packet is classified:

• Only consider flow policies whose FlowPolicy.FlowID match the classification of thepacket

• Only consider flow policies whose FlowPolicy.PathID is available

• If no flow policies match, use default policies

• If one or several flow policies matches, consider the one with the highest FlowPol-icy.priority

• Use the FlowPolicy.PathID of the selected flow policy to route the packet, if it is a nullPathID, drop the packet

If the packet is unclassified (default settings), use the same algorithm with the followingchanges: Try to match flow policies whose FlowPolicy.FlowID is null. If, finally, no flowpolicies match, use any available PathID.

If several ’Flow policies’ have the same priority, the ’IPv6 Forwarding’ module arbitrarilychooses one of them. In this case, the ’IPv6 Forwarding module’ has to ensure not to route asingle connection alternatively to several PathID. The meaning of a connection is describedin the ’IPv6 Traffic identifier module’.



7.3 Required actions

The ’IPv6 forwarding’ module receives IPv6 packets from its ’external IPv6 interface(s)’, its’ITS LAN IPv6 interface(s)’ or the layer above through the ’NF interface’:

• The ’IPv6 forwarding’ module shall maintain the information necessary about IPv6neighbors in order to determine the next IPv6 hop towards a destination reachablethrough an IPv6 interface to perform the forwarding function.

• Whenever the ’IPv6 forwarding’ module receives an IPv6 packet, it shall perform IPnext hop determination and IPv6 address resolution and forward the packet to the ap-propriate interface (or the layer above if intended for itself) as specified in its forwardingtable.

The forwarding table shall be updated by the SME (ISO 21217 figure 13) based on theavailability of communication interfaces and needs of the applications:

• Default settings of the forwarding table shall be requested from the SME through theMN-SAP using N-COMMAND.request instructions as specified in ISO 24102.

• Whenever the ’IPv6 forwarding’ module receives N-COMMAND.request instructionsfrom the SME through the MN-SAP, it shall modify the forwarding table as specifiedin ISO 24102.


CHAPTER 8

Module IPv6 mobility support

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to allow an ITS station to maintain continuous IPv6 connectivity while chang-ing its point of attachment to the network. This is ensured by the IPv6 mobility supportmodule within the IPv6 protocol block. The IPv6 mobility support module comprises mecha-nisms for maintaining IPv6 global addressing, Internet reachability, session connectivity andmedia-independent handovers (handover between different access technologies) for in-vehiclenetworks. This module mostly combines Network Mobility Basic Support (NemoBS) [rfc3963]and M Multiple Care-of Addresses Registration (MCoA) [rfc5648].

8.1 IPv6 network mobility basic support (NEMO)

The Network Mobility Basic Support (NemoBS) [rfc3963] is designed to maintain Internetconnectivity between all the nodes in the vehicle and the infrastructure (network mobilitysupport). This is performed without breaking the flows under transmission, and transparentlyto the nodes located behind the MR (MNNs) and the communication peers (CNs). This ishandled by mobility management functions in the MR and a server known as the HA (’HomeAgent’) located in an IPv6 subnet known to the MR as the ’home IPv6 link’.

The key idea of NemoBS is that the IPv6 mobile network prefix (known as MNP) allo-cated to the MR is kept irrespective of the topological location of the MR while a bindingbetween the MNP and the newly acquired temporary ’Care-of Address’ (CoA) configuredon the external IPv6 egress connecting the MR to the Internet is recorded at the HA. Thisregistration is performed by the MR at each subsequent point of attachment to an AR. Inorder to do this, the MR is using its global address known as the ’Home Address’ (HoA).

This allows a node in the vehicle to remain reachable at the same IPv6 address as longas the address is not deprecated. The HA is now able to redirect all packets to the currentlocation of the vehicle. MNNs attached to the MR do not need to configure a new IPv6address nor do they need to perform any mobility support function to benefit from theInternet connectivity provided by the MR. This mobility support mechanism provided byNEMO is thus very easy to deploy, at a minimum cost.

The tunnel between the MR and the HA may be implemented as a virtual IPv6 interfacepointing to a physical egress interface (’external IPv6 interface’) where packets would be

72


encapsulated. Such an IPv6 virtual interface would then be treated by the routing module asthe physical external IPv6 interface. The same rules would thus be applied to the selectionof the MR-HA tunnel (see the IPv6 forwarding module in 7.

The earlier Mobile IPv6 mobility support specification [rfc3775] provides Internet con-nectivity to a single moving IPv6 host only (IPv6 host mobility support). Mobile IPv6 istherefore inappropriate for the most advanced ITS use cases which usually consider morethan one in-vehicle embedded CPU. Network mobility support using RFC 3963 also supportssituations where there would be only a single IPv6 node deployed in the vehicle. Indeed, theability to support an entire network of n nodes includes the ability so support a network of1 node only. So just considering ’NEMO Basic Support’ and not considering ’Mobile IPv6’makes the ITS station architecture much simpler.

The operation of NEMO Basic Support is illustrated in Fig. 8.1

Figure 8.1: IPv6 session continuity with NEMO Basic Support

For a better understanding of NEMO, the terminology is specified in [rfc4885] and thedesign goals behind NEMO Basic Support in [rfc4886]. These documents are normativedocuments for how to apply ’NEMO Basic Support’ to the ITS station architecture.

8.2 IPv6 mobile edge multihoming (MCoA)

[rfc5648] is an extension to Mobile IPv6 [rfc3775] and NEMO Basic Support [rfc3963] andallows a MR to register multiple Care-of Addresses (CoA) with its HA.

As a result of the notification of the tunnel set-up from the IP ’mobility management’module to the ’ITS station management entity’, the ’ITS station management entity’ should



notify the ’IPv6 forwarding’ module with new forwarding table entries. See the descriptionof the IPv6 forwarding module.

Different approaches have been proposed at the IETF in the former MEXT WorkingGroup for the MR and the HA to synchronize their decisions in choosing the appropriatemedium [rfc6088] and [rfc6089]. One such approach is to exchange rules (routing policies)using NEMO signaling messages; another is more generic and uses standard transport layerprotocols. The rules for performing handovers and medium switching are configurable bystakeholders, e.g. users, device vendors, service providers, OEMs, car manufacturers. Theserules are competitive factors among stakeholders, so the definitions of these rules are outsidethe scope of the ITS station set of standards.

The operation of MCoA is illustrated in Fig. 8.2

Figure 8.2: IPv6 mobile edge multihoming


The ’mobility management’ module’ shall implement mobility support functions for Internetreachability and session continuity as specified in RFC 3963 ’NEMO Basic Support protocol’.

A bidirectional tunnel shall be established between the ’ITS-S IPv6 mobile router’ andthe ’ITS-S IPv6 home agent’ for every global IPv6 address available on any ’external IPv6interface’.

The maintenance of multiple tunnels simultaneously available between the ’ITS-S IPv6mobile router’ and the ’ITS-S IPv6 home agent’ (HA) shall be achieved in accordance toRFC 5648 ’Multiple Care-of Addresses Registration’ (MCoA).



Whenever the IPv6 address of tunnel end-point changes, the ’mobility management’module shall notify the ’ITS station management entity’ through the MN-SAP using N-REQUEST.request instructions as specified in ISO 24102.

When multiple tunnels exist, ’ITS-S IPv6 mobile router’ and the ’ITS-S IPv6 home agent’shall be synchronized in order to make decisions based on the same criteria (user choices,network availability, media characteristics and type of flow) in both directions. This shallbe achieved by an exchange between the ’ITS-S IPv6 mobile router’ and ’ITS-S IPv6 homeagent’ of the rules notified by the ’ITS station management entity’ to the ’IPv6 forwarding’module.


CHAPTER 9

Module IPv6 ad-hoc networking

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to allow ad-hoc IPv6 communications between nearby ITS stations. This isensured by the IPv6 ad-hoc networking module within the IPv6 protocol block. The IPv6ad-hoc networking module is currently limited to the IPv6 Internal Network Prefix Discovery(INPD) protocol defined on purpose. In the future, it might be extended with other features.INPD is designed to optimize routing between two neighbor ITS stations. Contrary to otherprotocols, there doesn’t exist such a standard specified by the IETF, so a new protocol isdesigned on purpose.

9.1 IPv6 Internal Network Prefix Discovery (INPD)

9.1.1 INPD: Motivations

As specified in [ISO-21210], Internet connectivity and session continuity for ITS stationschanging their point of attachment are provided by NBS! (NBS!) [rfc3963]. NBS! (NBS!)maintains a tunnel between mobile router (MR) in e.g. a vehicle ITS station router and homeagent (HA) in e.g. a central ITS station router. As a result of the use of NBS! (NBS!),all data packets emitted to or from the MR have to be routed through the HA. Due to this,routing can become extremely inefficient.

Routing is clearly inefficient in communication scenarios where a vehicle ITS stationcommunicates with another nearby ITS station (vehicle or roadside), particularly when thetwo neighbors ITS stations are on the same IPv6 wireless link, i.e. one IPv6 hop away. Itis even more inefficient for communications between two neighbor vehicle ITS stations whichare registered with distinct HA (e.g. in the situation where the two cars are registered indistinct countries or are from distinct car makers). In this case, packets would go through twotopologically distant HAs, and may be sent twice on the same wireless link if the same mediais used to access the Internet. In other words packet transmission performance is inefficientin some communication scenarios due to the tunnel established by NBS! (NBS!). However,this tunnel is necessary to maintain Internet connectivity and reachability, so a mechanism isneeded to allow direct routing between two adjacent ITS stations in addition to maintainingInternet connectivity and reachability.

In order to skip the HA and transmit packets over an optimal path, extensions to NBS!

76


(NBS!) known as Routing Optimization have been proposed, and implemented, bearingvery efficient performance results. However, no solution has been standardized yet at theIETF though this was undergoing in the former MeXT Working Group (see the RoutingOptimization Problem Statement [rfc4888] and the Routing Optimization [rfc4889] taxonomyRFCs).

The approach adopted for direct routing between adjacent ITS stations is to announce theinternal network prefix of vehicle and roadside ITS stations (IINP) to adjacent ITS stationsand let them update routing tables accordingly. In addition, the ability to route directly tonodes attached to neighbor MRs and ARs must be combined with the ability for the MR toroute packets to the HA i.e. backward compatibility withNBS! (NBS!) must be maintained.

Without this specific mechanism, IPv6 routers on the IPv6 link would only know theirrespective link-local address or CoA, but not their associated IPv6 prefixes. It would thus notbe possible for a node attached to an ITS station (MR or AR) to communicate with a nodeattached to another ITS station without transiting through the HA. In other words, withoutINPD, a router wouldn’t be able to send packets to the IPv6 nodes attached to neighborrouters one IP hop away unless a NEMO tunnel is available, in which case all packets sentfrom the in-vehicle network would be routed via the HA. Accordingly, INPD improves routingperformance by allowing direct communication between any two nodes attached to distinctITS stations.

IPv6 Internal Network Prefix Discovery (INPD) has originally been defined by the GeoNetproject and was then known as Mobile Network Prefix Provisioning (MNPP)1. MNPP wasdesigned to announce only a vehicle ITS station’s internal network prefix, known as the mobilenetwork prefix (MNP) in the context of NBS! (NBS!). MNPP has thus been extended andrenamed to INPD in order to remove its naming dependency with the NEMO terminology.

9.1.2 INPD: Description

The INPD protocol enables direct routing between adjacent ITS stations neighbor ITS stationrouters (MRs and ARs). The procedure to discover adjacent ITS station’s internal networkprefixes is defined as IPv6 Internal Network Prefix Discovery (INPD). It allows ITS stationsto advertise the IPv6 prefix of the ITS station’s internal network to 1-IP-hop away neighborrouters. INPD transmits solicitation and advertisement messages between routers located onthe same conventional IPv6 wireless link (i.e. non-IP 1-hop) or IPv6 GeoNetwork link (i.e.non-IP multi-hop). As a result, all routers in the vicinity are able to establish a direct routeto the ITS station internal network of the other routers attached to the IPv6 link.

In order to advertise the ITS station’s internal network prefix, two messages are defined.The internal network prefix advertisement (INPA) are sent to announce the ITS station’sinternal network prefix whereas the internal network prefix solicitation (INPS) messages areused to request INPA messages quickly.

INPA messages contain at least the internal network prefix and the preferred lifetime andare sent onto the ITS station router’s external IPv6 interface. One-hop away ITS stationrouters receive the INPA message and learn from these messages the link-local address of thesending ITS station router. Upon reception of the INPA messages, the receivers (neighborrouters) update their routing tables so that packets destined to the internal network prefixare directly routed to the link-local address. This direct routing remains until the preferredlifetime for the internal network prefix has expired, but this lifetime can be adjusted accordingto the receiver’s local policy.

1see GeoNet D2.2 [GeoNet-D2.2] Section 9.4.5 for a more detailed description



Figure 9.1: Message Flow Example in INPD Proactive Mode.

9.1.3 INPD: Interaction with other modules

The IPv6 Internal Network Prefix Discovery (INPD) protocol interacts with the followingIPv6 modules:

• IPv6 Adaptation Agent Module: The interaction with the IPv6 adaptation agent mod-ule is required to interpret MN-COMMAND and MN-REQUEST transmitted betweenthe IPv6 protocol block of the ITS station networking & transport layer (SNT) and theITS station management entity (SME) and related to INPD operations.

• IPv6 Forwarding Module: The interaction with the IPv6 Forwarding module is requiredto update routing information associated with 1-IP-hop away neighbor routers. It oc-curs when the IPv6 INPD module successfully obtains 1-IP-hop away neighbor router’slink-local address, internal network prefix, and preferred lifetime.

• IPv6 Security Module: The interaction with the IPv6 Security module is required tosecure the process of INPD.

• External IPv6 Interface Module: The interaction with the External IPv6 Interfacemodule is required to send/receive INPAmessages from 1-IP-hop away neighbor routers.

9.1.4 INPD: Message flows

INPD has two mode of operation, proactive and reactive:

• Proactive method: The ITS station router (MR or AR) periodically sends the unso-licited INPA messages containing the internal network prefix being used in its internalnetwork. Upon reception of the INPA message, adjacent ITS stations (i.e., 1-IP-hopaway neighbor routers) obtain the internal network prefix of the sender. It is similarto the case of sending unsolicited router advertisement messages defined in NeighborDiscovery Protocol.

• Reactive method: The ITS station router (MR or AR) upon reception of the INPSmessage immediately sends the solicited INPA message containing the internal networkprefix being used in its internal network. The INPS message should be used to promptadjacent ITS stations (i.e., 1-IP-hop away neighbor routers) to generate the INPAmessage quickly. It is similar to the case of requesting solicited router advertisementmessage in Neighbor Discovery Protocol.



9.1.4.1 INPD: Proactive mode message flows

MR multicast its INPA messages periodically. For such a unsolicited INPA message, thesource address must be set to the MR’s link-local address and the destination address mustbe set to the all-nodes multicast address (FF02::1). The INPA message sent from the MRhas the ICMPv6 type field set to 199 and should have several flags, fields and options: V(vehicle ITS station configuration) flag or R (roadside ITS station configuration) flag, sourcelink-layer address (SLLA), internal network prefix (INP), internal network prefix’s preferredlifetime (PLT), and internal network prefix’s MTU. Note that the internal network prefix andassociated preferred lifetime must be presented in the INPA message.

Neighbor nodes receive the INPA message sent from the MR. They then update theirrouting table information based on the information contained in the INPA message. Notethat the source link-layer address can be obtained from the INPA message’s source addressfield or from the source link-layer address option field.

The message flow of the proactive mode is presented in Figure 9.1. INPA messages aresent by MR1 and received by MR2, AR3. As shown in Figure 9.1, if host2 attached to theMR2 sends data packets destined to host1, those packets are directly sent to MR1 from MR2,and not sent to MR1’s HA. The following example shows the conceptual unsolicited INPAmessage’s sent from MR1:

/* INPA message periodically sent from the mobile router */IPv6 header (src=FE80::260:97FF:FE02:6EA9, dst=FF02::1, next hr=58)

ICMPv6 header (type=199, V flag)- Source link-layer address (00-60-97-02-6E-A9)- Internal network prefix (INP) with assiciated preferred lifetime (PLT)

9.1.4.2 INPD: Reactive mode message flows

There are two situations within the reactive mode to quickly obtain neighbor’s internal net-work prefixes: the INPS message may be multicast to all neighbor nodes, or sent uniquelyto a given neighbor node. The message flow of the reactive mode is presented in Figures 9.2and 9.3.

In the situation where a node (MR or AR) sends its INPS message to all neighbor nodes,the source address of the INPS message is set to the sender’s link-local address whereas thedestination address is set to the all-router multicast address (FF02::2). The ICMPv6 typefield is set to 198. As a possible option, the source link-layer address option is included.Neighbor nodes receive the INPS message. They then immediately respond with a INPAmessage sent directly to the requester. In other words, the solicited INPA message is sent ina unicast manner in response to the INPS message. In the other situation where the INPSmessage is sent to a given node, the destination address of the INPS message is set to thatparticular node, which respond to the sender with an INPA message as explained for the firstcase.

Figure 9.2 illustrates the case where MR2 sends its INPS message to all neighbor nodes.The INPS message is received by MR1 and AR3. The source address of the solicited INPAmessage sent from MR1 is set to MR1’s link-local address (FE80::260:97FF:FE02:6EA9).The following is the conceptual INPS/INPA message related to Figure 9.2.

/* INPS message to prompt all neighbors to send INPA messages quickly */IPv6 header (src=FE80::210:5AFF:FEAA:20A1, dst=FF02::2, next hr=58)

ICMPv6 header (type=198, V flag)- Source link-layer address (00-60-97-02-6E-A1)



Figure 9.2: Message Flow Example in the INPD Reactive Mode: A node sends its INPSmessage to all neighbor nodes to quickly obtain neighbor node’s internal network prefixes.

Figure 9.3: Message Flow Example in the INPD Reactive Mode: A node sends its INPSmessage to a specific node to quickly obtain the specific node’s internal network prefix.

/* INPA message in response to the INPS message */IPv6 header (src=FE80::260:97FF:FE02:6EA9, dst=FE80::210:5AFF:FEAA:20A1, next hr=58)

ICMPv6 header (type=199, V flag)- Source link-layer address (00-60-97-02-6E-A9)- Internal network prefix (INP) with associated preferred lifetime (PLT)

Figure 9.3 illustrates the case where MR2 sends its INPS message to a specific nodei.e. MR1. The destination address for the INPS message is the specific node’s address,i.e., MR1’s address (FE80::260:97FF:FE02:6EA9). When MR1 receives the INPS message,it immediately responds with an INPA message sent back to MR2. The following is theconceptual INPS/INPA message related to Figure 9.3:

/* INPS message to prompt a specific node to send a INPA message quickly */IPv6 header (src=FE80::210:5AFF:FEAA:20A1, dst=FE80::260:97FF:FE02:6EA9, next hr=58)

ICMPv6 header (type=198, V flag)- Source link-layer address (00-60-97-02-6E-A1)

/* INPA message in respond to the INPS message */IPv6 header (src=FE80::260:97FF:FE02:6EA9, dst=FE80::210:5AFF:FEAA:20A1, next hr=58)

ICMPv6 header (type=199, V flag)- Source link-layer address (00-60-97-02-6E-A9)- Internal network prefix (INP) with associated preferred lifetime (PLT)


CHAPTER 10

Module IPv6 over GeoNetworking

10.1 IPv6 over GeoNetworking: description

IPv6 GeoNetworking is the combination of IPv6 networking capabilities together with GeoNet-working capabilities. Typically, routers (MRs and ARs) with GeoNetworking capabilities areable to transmit IPv6 packets over a multi-hop link made of forwarding ITS stations (vehi-cles, and possibly roadside). Associated with IPv6 multicast capabilities, routers with IPv6GeoNetworking capabilities are able to distribute IPv6 packets to a set of nodes located in agiven geographical area, either around the sending node or at a remote geographical location.

The mechanisms combining IPv6 and GeoNetworking have originally been defined by theGeoNet European Project, taking as an input the GeoNetworking capabilities defined bythe Car2Car Communication Consortium and IPv6 networking defined in ISO 21210. Thearchitecture [GeoNet-D1.2] and the specification [GeoNet-D2.2] are publicly available andcan be found on the GeoNet European Project web site [url-GeoNet]. At a later stage, asubset of the GeoNet work has been standardized by ETSI TC ITS.

Once IPv6 is combined with GeoNetworking, the network layer is composed of two sub-layers which are pilled up. IPv6 being above GeoNetworking. IPv6 performs all the conven-tional IPv6 layer functions plus IPv6 mobility management functions (vertical handovers andmultihoming) while GeoNetworking is in charge of the routing functions based on geographicpositions of the vehicles). GeoNetworking indeed appears as a link layer from the point ofview of the IPv6 layer, which means that IPv6 is unaware of the GeoNetworking capabilities.As such, an IP packet is transferred to the GeoNetworking layer where it is encapsulated andtransmitted through any number of intermediate vehicles until it reaches the next IP hop.

Such a module was proposed by the GeoNet project and is detailed in citeGeoNet-D2.2Routers with GeoNetworking capabilities are forming a particular case of vehicular ad-hoc

network (VANET). MRs and ARs combining both IPv6 and GeoNetworking capabilities andlocated in a bounded geographical area form an IPv6 sub-network and are reachable on aunique virtual IPv6 link, which is referred to as the IPv6 C2CNet link. Taking a look atFigure XX 10 XX, MR3 and AR2 are on the same IPv6 link although there is an intermediaterouter (MR4) in between. The actual topology of the network is thus hidden to the MRs atthe IPv6 layer, but known at the C2CNet layer below the IPv6 layer.

MRs and ARs attach to this IPv6 link through an egress interface referred to as theC2CNet egress interface. All routers on this IPv6 C2CNet link are configuring their IPv6

81


addresses using standard stateless address auto-configuration (SLAAC) [rfc4862].When a packet is received by a router (AR or MR) which comprises a C2Net egress

interface, the router must first determine the next IP hop. This is performed in a conventionalway, according to the information registered in the IP forwarding table.

If the next IP hop determination leads to a router reachable on the IPv6 C2CNet link,the packet must be transmitted through the C2CNet egress interface. In order to do so,the packet is first transmitted to the C2CNet layer through the internal C2C-IP SAP. TheC2CNet layer determines the C2CNet ID (aka of MAC address) of the next IP hop andtransmit the packet using GeoNetworking functions.

The process of packet delivery over the IPv6 C2CNet link is fully detailed in [GeoNet-D1.2](Section 7).

A function similar to IPv6 over C2CNet has been specified by ETSI [ETSI-TS-102-636-6-1]but is currently incomplete.

10.1.1 GeoNetworking Layer

GeoNetworking is the ITS station networking & transport protocol block performing geo-graphic addressing and routing functions. It corresponds to the GeoRouting component ofthe ITS station.

GeoNetworking is indeed a layer, which plays a crucial role as it is in charge of thegeographic addressing and forwarding functions, i.e. forwarding a packet destination nodeslocated in a given geographic area.

Details of the GeoNetworking layer can be found in the publicly available GeoNet deliver-able [GeoNet-D2.2] . Most of the GeoNetworking capabilities specified by the GeoNet projecthave since been taken over by ETSI TC ITS and are specified as [ETSI-TS-102-636-4-1,ETSI-TS-102-636-4-2]. In the GeoNet project, the GeoNetworking layer was originally re-ferred to as the C2CNet layer.

In brief, the GeoNetworking layer provides the following set of functionalities:

• Geo-position calculation: implemented in all MRs and ARs with GeoNetworking capa-bilities, this module is responsible for calculating the position information to be usedfor GeoNetworking. This modules is also responsible for geographical relevance check.

• GeoRouting: implemented in all MRs and ARs with GeoNetworking capabilities, thismodule is in charge of forwarding packets from a source to a destination based ongeographical information such as position or velocity. It is composed of following sub-modules: GeoUnicast, GeoBroadcast, GeoAnycast, TopoBroadcast and Store and for-ward. Store and forward is a sub-module that stores the packet locally for a definedperiod of time when the forwarding of the packet is not possible. The GeoRouting func-tion is based on the GPSR (Greedy Perimeter Stateless Routing for Wireless Networks)routing algorithm.

• Location management: implemented in all MRs and ARs with GeoNetworking capabil-ities, this module manages location information among communication peers (positioncalculation and maintenance of the neighboring nodes position). It is composed of thefollowing sub-modules:

– Beaconing: This sub-module keeps transmitting a periodic packet to inform itsneighbors about its presence. This packet is called network beacon, and containsonly the common header (as defined by C2C-CC) which contains a position vectorto inform about own position information.



– Location table: This sub-module is used to record locally the location informationof neighbors and other potential destination nodes.

– Location service: This sub-module resolves the geographic location of a commu-nication peer when location table has no valid entry for it.


The IPv6 over GeoNetworking module behaves as a IPv6 External Interface module. It allowsIPv6 packets to be encapsulated and sent to the next IP hop through the IPv6 GeoNetworkinglink. It thus performs IP address resolution over the IPv6 GeoNetworking link in order totransmit packet to nearby MRs and ARs in the vicinity and transmits the IPv6 packetsbetween the IPv6 layer and the GeoNetworking layer in the appropriate format.


CHAPTER 11

Module IPv6 security

11.1 Overview

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to secure IPv6 communications. This is ensured by the IPv6 security modulewithin the IPv6 protocol block. The IPv6 security module performs the functions required atthe IPv6 layer to secure both IPv6 signaling and IPv6 payload. It comprises security protocolssuch as SeND, IPsec, Shared-key-based authentication, etc. offering the service mechanismsdefined in [X.800, Lee2011b]. It interacts with the ITS station security entity (SSE), with theITS station management entity (SME) and other IPv6 modules. The IPv6 security moduleis defined to:

• implement security mechanisms necessary for achieving required security services throughsecurity protocols;

• map the security services onto the security mechanisms;

• enable the security protocols for the required security services;

• apply the security mechanisms requested for packets of a given flow

Security atomic operations such as arbitrary bit generation, hashing, signing/verification,and encryption/decryption are performed in the ITS station security entity (SSE) when suchoperations are requested from the IPv6 security module [Lee2011b, Lee2012a], for instancewhen the IPv6 security module requests an arbitrary bit string for location privacy. Theinteractions between the SSE and the IPv6 security module is performed via the SN-SAP, ina security mechanism/protocol agnostic way so that the behavior of the ITS station securityentity does not depend on any type of security mechanism or protocol.

The IPv6 networking protocol block informs the ITS station management entity (SME)about its capability to perform the security services defined in [X.800]. Requirements forsecurity services to be applied on a given flow are provided by the ITS station managemententity (SME) to the IPv6 networking protocol block, so that the IPv6 traffic classifier moduleis able to determine on which IPv6 interface packets should be provided. The IPv6 securitymodule performs the required security mechanisms/protocols for IPv6 packets of a given flow.The communication (e.g., informing the security service capability from the IPv6 security

84


module of the IPv6 networking protocol block to the SME, informing the required securityservices for a given flow from the SME to the IPv6 security module of the IPv6 networkingprotocol block) between the SME and the IPv6 networking protocol block is performed viathe MN-SAP.

The text in this chapter is being contributed to the new ISO work item CALM: IPv6Networking Security (ISO 16788) started under the initiation of ITSSv6 project members.

A security service is a service provided by a system to ensure adequate security to re-sources of the system or of other systems. Security services are implemented via securitymechanisms/protocols. Security services and mechanisms are defined by ITU-T [X.800] anddescribed in Sections 11.2.1 and 11.2.2.

11.2 ITU’s definition of security services and mechanisms

11.2.1 Security services

The following security services are defined as [X.800]:

• The peer entity authentication service defined in X.800 provides the corroboration thata peer entity in an association is the one claimed;

• The data origin authentication service defined in X.800 provides the corroboration thatthe source of the data received is as claimed;

• The access control service defined in X.800 provides protection against unauthorizeduse of resources;

• The connection confidentiality service defined in X.800 provides for the confidentialityof all user data on a connection;

• The connectionless confidentiality service defined in X.800 provides for the confiden-tiality of all user data in a single connectionless data unit;

• The traffic flow confidentiality service defined in X.800 provides for the protection ofthe information which may be derived by observing traffic flow;

• The connection integrity without recovery service defined in X.800 provides for theintegrity of all user data on a connection. It also provides the detection ability for anymodification, insertion, deletion, or replay of user data within an entire data unit withno recovery attempted;

• The connectionless integrity service defined in X.800 provides for the integrity of a singleconnectionless data unit. It also may provide the detection ability for any modificationof user data and the limited detection ability for replay of user data; and

• The location privacy support service, which is not a security service defined in X.800but particularly required for mobile ITS stations (e.g., vehicle ITS station), providesprotections against observers examining user data to extract location information.

11.2.2 Security mechanisms

The following security mechanisms are defined as [X.800]:



• Cryptographically derived or protected authentication exchange mechanism: It can beused to provide the peer entity authentication service.

• Signature mechanism: It consists of message signing and message verifying. The peerentity authentication service and data origin authentication service can be achieved bythe digital signature mechanism.

• Encipherment mechanism: It provides confidentiality of either data or traffic flow. Itcan be used as a part in or complement a number of other security mechanisms. Thedata origin authentication service, connection confidentiality service, and connectionlessconfidentiality service can be achieved by the encipherment mechanism.

• Access control mechanism: It is used to provide the access control service, i.e., toprovide protection against unauthorized use of resources/services. The provision ofaccess control is a nontrivial security service which involves the application of differentsecurity mechanisms. On the one hand, authentication mechanims are needed to ensurethe authenticity of a peer entity requesting access to a resource. On the other hand,authorization mechanisms are required to determine and apply the peer entity’s accessrights.

• Routing control mechanism: It provides a dynamic or pre-defined routing to use onlyphysically secure sub-networks, relays, or links. The connection confidentiality ser-vice and connectionless confidentiality service can be achieved by the routing controlmechanism.

• Traffic padding mechanism: It can be used to provide protection against traffic analysis.It can be effective only if the traffic padding is protected by a confidentiality mechanism.The traffic flow confidentiality service can be achieved by the traffic padding mechanism,in conjunction with a confidentiality mechanism.

• Data integrity mechanism: It can be used to provide the connection integrity withoutrecovery service and connectionless integrity service, sometimes in conjunction with anencipherment mechanism.

• Pseudonym configuration mechanism: It can be used to preserve location privacy. Itutilizes a set of pseudonyms in IPv6 address and communication. The pseudonymconfiguration mechanism is not the security mechanism defined in [X.800] and is onlyrequired to the IPv6 security module deployed in vehicular and personal ITS subsys-tems. The pseudonym configuration mechanism utilizes a set of pseudonyms that aretemporary identifiers (generated from arbitrary bit string) for IPv6 communications.

11.3 Security services offered by the IPv6 security module

The IPv6 security module provides the following security services, mostly defined in [X.800]and outlined in 11.2.2:

• Authentication service: The IPv6 security module shall assure that IPv6 communica-tions between ITS stations are authentic in terms of peer entity authentication anddata origin authentication services. The peer entity authentication service provides thecorroboration that a peer entity in an association is the one claimed, whereas the dataorigin authentication service provides the corroboration that the source of the datareceived is as claimed.



• Access control service: The IPv6 security module shall have the ability to limit andcontrol any access via IPv6 communications.

• Confidentiality service: The IPv6 security module shall provide the protection of IPv6communications from unauthorized disclosure in terms of connection confidentiality,connectionless confidentiality, and traffic flow confidentiality services. The connectionconfidentiality service provides for the confidentiality of all user data on a connection,whereas the connectionless confidentiality service provides for the confidentiality of alluser data in a single connectionless data unit. The traffic flow confidentiality serviceprovides for the protection of the information which may be derived by observing trafficflow.

• Integrity service: The IPv6 security module shall provide the protection of IPv6 com-munications from unauthorized modification in terms of connection integrity withoutrecovery and connectionless integrity services. The connection integrity without recov-ery service provides for the integrity of all user data on a connection. It also providesthe detection ability for any modification, insertion, deletion, or replay of user datawithin an entire data unit (with no recovery attempted). The connectionless integrityservice provides for the integrity of a single connectionless data unit. It also may pro-vide the detection ability for any modification of user data and the limited detectionability for replay of user data.

• Location privacy support service: The IPv6 security module shall provide the necessaryfunctionality that allows vehicular and personal ITS-S subsystems to preserve locationprivacy from observers examining the header of IPv6 packets. The location privacysupport service is not the security service defined in [X.800]. This security service isspecially required for vehicular and personal ITS-S subsystems that have mobility atthe IPv6 layer.

Figure 11.1 shows the mapping between security services and security mechanisms asthey can be provided by the IPv6 layer. The security services are provided in differentcombinations according to the type of ITS station IPv6 node, as illustrated on Figure 11.2.Similarly, the security mechanisms are provided in different combinations according to thetype of ITS station IPv6 node, as illustrated on Figure 11.3.

11.4 IPv6 security protocols implementing security services

In order for the IPv6 layer to provide the above security services, a number of securityprotocols must be implemented. These are:

• SeND (SEcure Neighbor Discovery) as specified in [rfc3971] for securing the neighbordiscovery protocol (NDP) [rfc4861] which operates between vehicle and roadside ITSstations.

• IPsec, as specified in [rfc4301] and other RFCs for securing all types of IPv6 trafficincluding NEMO signaling [rfc3776];

• Shared-key-based authentication as specified in [rfc4285] ‘Authentication Protocol forMobile IPv6’ for securing location update signaling.

• A pseudonym configuration mechanism for providing location privacy from IPv6 ad-dresses [rfc4941];



Figure 11.1: Security services achieved by security mechanisms at the IPv6 layer



Figure 11.2: Mapping of security services to types of IPv6 node

Figure 11.3: Mapping of security mechanisms to types of Pv6 node



Figure 11.4: Security mechanisms provided by IPv6 security protocols

• Lightweight Authentication for NEMO Signaling [rfc4285] for securing NEMO signaling;

• Cryptographically Generated Address (CGA) [rfc3972] for generating an IPv6 addressfor which the rightmost 64 bits of the IPv6 address, i.e., interface identifier, is generatedby computing a cryptographic one-way hash function from a public key and auxiliaryparameters [Lee2012a].

These protocols are subject to be modified or replaced if better ones appear in future.Figure 11.4 shows the security mechanisms provided by the identified security protocols.

The security protocols are provided in different combinations according to the type ofITS station IPv6 node, as illustrated on Figure 11.5.

The security protocol are required to protect IPv6 packets passing to both the externalIPv6 interface(s) and the internal IPv6 interface(s) (interface to the ITS station IPv6 LAN),as illustrated on Figure 11.6.

Location update signaling, i.e., NEMO’s binding update (BU) and binding acknowledge-ment (BA) messages is protected either by IPsec or the shared-key-based authentication. Theshared-key-based authentication, which produces less signaling overhead than IPsec is onlyrecommended in certain cases, when , e.g., no location privacy is required, or access networkauthentication is established by other means.

11.5 Interaction with other modules and entities

The IPv6 security module’s primary role is to enforce the security services to incoming andoutgoing packets/sessions. The determination of the security services to be applied on a given



Figure 11.5: Mapping of security protocols to types of IPv6 node

Figure 11.6: Mapping of security protocols according to the type of interface (internal andexternal)



flow comes from the SME. The execution of the security services at the IPv6 layer is doneby the IPv6 security module that relies on dedicated IPv6 security mechanisms/protocols.

Close relations are required between the IPv6 networking protocol block and the SME,and between the IPv6 networking protocol block and the SSE. Upon reception of a requestfor activating a specific security service, the IPv6 security module of the IPv6 networkingprotocol block maps the security service onto available security mechanism(s)/protocols(s)and activates security mechanism(s)/protocol(s) for the security service.

Similarly, upon reception of a request for deactivating a specific security service, the IPv6security module maps the security service onto activated security mechanism(s)/protocol(s)and deactivates security mechanism(s)/protocol(s) for the security service if only the securitymechanism(s)/protocol(s) is not currently used to provide other security service(s).

11.5.1 Interaction with ITS station management entity

The ITS station management entity (SME) requests the IPv6 networking protocol blockto activates/deactivates security services and to update/lock pseudonyms. On the otherdirection, the IPv6 networking protocol block provides the ITS station management entity(SME) with a list of available security services per routing interface. This interaction isperformed through the MN-SAP using the MN-COMMAND and MN-REQUEST services.Details of the MN-SAP are provided in Section 14.

The actual communication with the ITS station management entity (SME) is madethrough the IPv6 adaptation agent module which interprets the MN-REQUEST and MN-COMMAND and interact with the IPv6 security module located at the IPv6 networkingprotocol block.

11.5.2 Interaction with ITS station security entity

The IPv6 security module communicates with the ITS station security entity (SSE) throughthe SN-SAP using the SN-COMMAND and SN-REQUEST services. Details of the SN-SAPare provided in Section 15.

The interactions with the SSE are mostly related to atomic security operations. Whenatomic security operations are needed by the IPv6 security dedicated mechanisms/protocols,those are requested to the SSE via the SN-SAP [Lee2012a]. For instance, when the shared-key-based authentication is used, required data (e.g. CoA, home address and mobility header)are passed to the SSE with some informative parameters such as the type of hash algorithm,data length, expected return value’s length, etc. via the SN-SAP. Then a result of the atomicsecurity operations (e.g. keyed hash value) is returned back to the IPv6 Security module viathe SN-SAP. Another example is a pseudonym change at the IPv6 layer. Suppose that avehicle ITS station’s MR is required to change its pseudonym to preserve location privacy.In this case, a new pseudonym generation is requested from the IPv6 security module to theSSE via the SN-SAP.

11.5.3 Interaction with other IPv6 modules

Within the IPv6 networking protocol block, the IPv6 security module interacts with thefollowing modules:

• IPv6 adaptation agent module A list of available security services per routing in-terface is provided from the IPv6 security module to the IPv6 adaptation agent modulewhen bootstrapping the IPv6 security module for the given routing interface is per-formed.



• IPv6 mobility support module For moving ITS stations (vehicle ITS station, per-sonal ITS station), an interaction with the IPv6 mobility support module is requiredto obtain mobility status.

• IPv6 adhoc networking module The interaction with the Internal Network PrefixDiscovery protocol is required to obtain neighbor status.

• IPv6 multicasting module The interaction with the IPv6 multicasting module isrequired to obtain the multicast status.

• IPv6 internal interface module The security check for incoming packets/sessionsfrom the IPv6 internal interface module is performed by the IPv6 security module. Onlyvalid packets/sessions are passed to other modules for further processing within the IPv6networking protocol block. After security protection to outgoing packets/sessions, thesecured packets/sessions are sent to the Internal IPv6 Interface module.

• IPv6 external interface module The security check for incoming packets/sessionsfrom the External IPv6 Interface module is performed by the IPv6 Security module.Only valid packets/sessions are passed to other module in the IPv6 networking protocolblock for further processing. After security protection to outgoing packets/sessions, thesecured packets/sessions are sent to the External IPv6 Interface module.

11.6 Pseudonym configuration at the IPv6 layer

Location privacy may be required, particularly for some users of mobile ITS stations de-ployed in vehicles or personal devices. This section provides a description of a pseudonymconfiguration mechanism utilizing a set of pseudonyms at the IPv6 layer.

11.6.1 Pseudonym

For location privacy, temporary identifiers, i.e., pseudonyms, are used with an appropriatechanging scheme, e.g., a vehicle ITS station uses its current pseudonym P1 in a short periodtP1 and changes P1 to a new one P2 for the next short period tP2 . By using these pseudonyms,attackers are not able (or at least not easily) to link different pseudonyms in order to identifythe vehicle ITS station emitting messages with these pseudonyms.

A pseudonym is interpreted in different forms depending on the layer/protocol. Here weassume that the pseudonym is an arbitrary bit string. For the access layer, the 48 bits of MACaddress are replaced by the pseudonym. For the GeoNetworking layer, the rightmost 48 bitsof the GeoNetworking address, which correspond to the MAC address, are also replaced bythe pseudonym. For the IPv6 layer, in the case of IPv6 stateless address autoconfiguration,we suggest that the rightmost 64 bits of IPv6 address, i.e., interface identifier, are generatedbased on the pseudonym. It is worth noting that the pseudonym is synchronously changedacross the entire ITS station stack. For instance, when a current pseudonym is changed to anew one, the whole MAC address is replaced by the new pseudonym, while the GeoNetworkingaddress and the IPv6 address are changed accordingly.

The IPv6 security module provides a pseudonym, which is randomly generated 48 bits, tothe external IPv6 interface module that generates the 64 bits of an interface identifier basedon the provided pseudonym. The external IPv6 interface module configures the 128 bits of aglobal IPv6 address based on the generated interface identifier.



Figure 11.7: Considered network topology.

11.6.2 Pseudonym configuration

11.6.2.1 Pseudonym update due to mobility

The IPv6 security module receives a new pseudonym from the security entity when the ITSstation mobile router changes its attachment point, i.e., network-level handover, through theSN-COMMAND service of the SN-SAP.

The address generated with the pseudonym is used as a source address, i.e., care-of address(CoA), in the BU message. In other words, whenever BU messages sent, new pseudonymsobtained from the security entity are used to update the mobility binding.

11.6.2.2 Pseudonym change due to the mobility lifetime expiration

The IPv6 security module receives a new pseudonym from the security entity before thelifetime of the mobility binding is expired through the SN-COMMAND service of the SN-SAP.

11.6.2.3 Pseudonym change due to the pseudonym lifetime expiration

The IPv6 security module receives a new pseudonym from the security entity before thelifetime of the current pseudonym is expired through the SN-COMMAND service of theSN-SAP.

11.6.3 Example of pseudonym change at the IPv6 layer

An example for the pseudonym change is provided that requires the SN-SAP and MN-SAPinvolvement. Fig. 11.7 shows the considered scenario wherein a vehicle ITS station imple-menting IPv6 mobility, i.e., NEMO, changes its attachment point from AR-1 to AR-2.

Fig. 11.8 shows the required procedures when the vehicle ITS station moves to the newnetwork of AR-2.



Figure 11.8: Pseudonym change.

The details of each step are as follows:

1. First, we consider a pseudonym change due to handover. Suppose that the vehicle ITSstation V moves to the new network of AR-2.

2. V receives a RA message containing the network prefix NP2 for the new network ofAR-2.

3. V is required to configure its new address (Care-of Address) CoA2 with NP2. However,in this step, a new pseudonym P2 instead of its previous pseudonym P1 or its MACaddress is used to generate CoA2 with NP2. For this, the networking & transport layerrequests P2 to the security entity via SN-REQUEST.request:

SN-REQUEST.request(CommandRef, SN-Request),

where SN-Request.No is set as 6 (PseuReq), while SN-Request.Value contains optionaland specific values for PseuReq. For instance, an internal identifier of P1, which is beingused, is carried out. As the security entity receives SN-REQUEST.request, it replies withSN-REQUEST.confirm:

SN-REQUEST.confirm(CommandRef, SN-ReqConfirm, ErrStatus),

where CommandRef is the same number obtained from SN-REQUEST.request, SN-ReqConfirmcontains P2 with other values, e.g., an internal identifier of P2, and ErrStatus indi-cates a successful provision of P2. Note that an error status is reported in ErrStatus,



e.g., when P2 cannot be retrieved or cannot be provided at this request time. Then, ifP2 is successfully provisioned, the networking & transport layer reports its pseudonymchange to the management entity via the MN-SAP. As P2 is provided to the networking& transport layer, it is used to generate CoA2 with NP2:

CoA2 = FU−L(NP2 ‖ EUI64(P2)),

where ‖ is a concatenation operation, EUI64(·) is an EUI-64 function that gener-ates the interface identifier based on P2, and FU−L(·) is a function for the modi-fied EUI-64 that inverts universal/local bit. For instance, suppose NP2 and P2 are2002:db8:1:2::/64 and 00:1D:BA:06:36:62, respectively. Let IIDP2 denotes the in-terface identifier generated based on P2. Then, by EUI64(P2), IIDP2 is obtained as00:1D:BA:FF:FE:06:36:62. Then, an unlinkable address, i.e., CoA2, with its previousaddress, is generated as 2002:db8:1:2:021d:baff:fe06:3662.

4. Before the use of CoA2 in unicast communication, the uniqueness should be checkedvia the duplicate address detection (DAD) procedure. Then, if CoA2 is unique, V usesCoA2 to inform its new location by sending a BU message to its home agent (HA). Thenew location of V is registered to the binding cache of HA.

5. The HA replies with the BA message to V .

6. Now, we consider a different case: a pseudonym change due to the expiration ofpseudonym. Suppose that the current pseudonym’s lifetime tP2 has expired. Then,V has to reconfigure its current Care-of Address CoA2 even if it has not moved toanother network. For this, the management entity sends the networking & transportlayer MN-COMMAND.request:

MN-COMMAND.request(CommandRef, MN-Command),

where MN-Command.No is set as 10 (PseuUpdate) and MN-Command.Value contains theinternal identifier of current pseudonym, i.e., P2. As the networking & transport layerreceives this command, it requests a new pseudonym to the security entity as likestep 3). After a successful provision of the new pseudonym P3, the networking &transport layer reports its pseudonym update to the management entity by sendingMN-COMMAND.confirm:

MN-COMMAND.confirm(CommandRef, MN-CmdConfirm, ErrStatus),

where CommandRef is the same number obtained from MN-COMMAND.request, MN-CmdConfirmcontains the optional confirmation data, e.g., internal identifier of P3, and ErrStatusindicates a successful provision of P3 or an error reason if the error occurs. Then,similar to the previous address generation, a new Care-of Address CoA3 is generatedas:

CoA3 = FU−L(NP2 ‖ EUI64(P3)),

where P3 is used for generating its new interface identifier IIDP3 . In order to checkthe uniqueness of CoA3, the DAD procedure is performed again.

7. V sends a new BU message containing CoA3 as a source address.

8. Upon receiving the BU message, the HA updates its binding cache for V and replieswith the BA message.



11.7 Access Control Mechanisms for IPv6 communications

As described in previous section, access control is a key security service that is appliedregardless of the ITS station node type. In the following, we present a description of thedifferent mechanisms that can be implemented at the IPv6 security module according to theparticular needs that may appear in ITS environments.

11.7.1 General overview of access control

Generally speaking, access control is defined as the process of limiting the access to resourcesin such a manner that only legitimate users can access these resources. The application ofaccess control implies the following processes:

• Authentication, intended to ensure that a certain entity is really who she claims to be.

• Authorization, intended to determine what resources can be accessed by a certain entityand under what conditions. This process consists of the following actions:

1. Obtain information about the entity requesting access to the resource. Typically,this information is stored in the form of attributes by authorization centres.

2. Determine the access rights of the entity. This step relies on the so-called securitypolicies which, taking as input the user’s information previously gathered, it isdetermined if the user is granted or denied access to the resource.

3. Enforce the application of access rights. This final action ensures that the specificconditions that limit the user’s access are applied.

In the ITS-S reference architecture, access control is a security service that can be providedat different layers: access, network & transport and facilities. The higher the layer, the finer-grained access control can be applied. For example, while at the access layer the accesscontrol can be applied to frames transmitted over a data link connection established betweentwo ITS station IPv6 nodes, at the facilities layer a more sophisticated and richer accesscontrol can be applied when an ITS station requests access to applications (e.g., road safety).The network & transport layer represents an intermediate level where access control candistinguish only between network layer entities.

At the time being, since we are discussing the security functionalities provided by the IPv6security module located at the networking & transport layer, the access control is applied tolimit the establishment of IPv6 communications and to reject unwanted connections.

Despite in the following we are going to focus on the security mechanisms available at theIPv6 security module, it is worth mentioning that the access control service may be providedby a combination of access control mechanisms implemented by the different layers integratingthe ITS-S architecture. For example, the application of an access control mechanism overIPv6 packets could require the invocation of a mechanism available at the facilities layer toauthenticate the communicating ITS stations.

11.7.2 Access control mechanisms provided by the IPv6 security module

Similarly to the access control mechanisms available at the OSI network layer, the accesscontrol mechanisms provided by the IPv6 security module can be classified in two differentgroups:



• Non-cryptographic access control mechanisms. This group refers to mechanismsthat do not rely on cryptographic operations (e.g., encipherment, signature, etc.) tolimit the establishment of IPv6 communications. These mechanisms may typically takeas input information from the IPv6 packet itself (origin/destination IPv6 address orport, protocol, TTL, TOS, ...) to match the specific IPv6 datagrams affected by theaccess control mechanisms.

• Cryptographic access control mechanisms. This group integrates mechanismsthat rely on cryptographic operations to limit the establishment of IPv6 communica-tions. For this reason, these mechanisms will interact with the ITS station securityentity through the SN-SAP to request the execution of atomic operation such as hash-ing, signing/verification, encryption/decrypting, arbitrary bit generation, etc.

Regardless of the type, the application of an access control mechanism requires the exis-tence of a policy that determines the effect of the access control mechanism, i.e., what kindof IPv6 communications are restricted and the type of limitation. According to the X.800specification, a repository called security management information base (SMIB) contains thenecessary information to enforce the appropriate security policies at the IPv6 security level.Nevertheless, this aspect is an open issue to be addressed in the ITS station architecturebeing defined by ETSI/ISO.

The most famous non-cryptographic access control mechanism is the Netfilter frameworkimplemented by Linux kernel. Netfilter allows the implementation of firewalling solutions byintercepting and manipulating IP packets send or received through interfaces. Basically, thistool is based on a table containing a set of rules that guide the filtering or transformationof IP packets. These tables can be administered through user-space programs like ip6tablesthat allows the insertion of rules implementing the policies to be applied over IPv6 packets.

Similarly, we can find examples of cryptographic access control mechanisms. In particular,as described in Fig. 11.4, the SeND and IPsec security protocols implemented within the IPv6security module provide a cryptographic-based access control mechanism.

The SeND protocol [rfc3971], used for securing the neighbor discovery protocol (NDP),uses CGAs (Cryptographically Generated Addresses) to make sure that the sender of a neigh-bour discovery message is the owner of the claimed address. Firstly, a public-private key pairis generated by the ITS-S IPv6 node (e.g., mobile router) before she can claim an address.Next, a CGA is formed by replacing the least-significant 64 bits of the 128-bit IPv6 addresswith the cryptographic hash of the address owner’s public key. Additionally, the NDP mes-sages are signed with the corresponding private key. Thus, the SEND protocol implementsan access control for IPv6 NDP packets send by a certain ITS-S IPv6 node which is based oncryptographic operations (public/private key pair generation, hashing, signature, etc.) whichmay be requested to the ITS station security entity through the SN-SAP.

Similarly, the IPSec security framework provides [rfc4301] cryptographic access controlwithin the IPv6 security module. For example, this security protocol is used for securingthe location update signalling [rfc3776] between the mobile router and the home agent. Theprotection of IPv6 packets can be performed by using two different protocols: AH (Authen-tication Header) or ESP (Encapsulating Security Payload). While AH supports integrityand data origin authentication to IPv6 packets, ESP offers a highest security protection byenabling confidentiality of IP message contents.

Before establishing an IPSec based access control, the involved ITS station IPv6 nodesare required to authenticate each other. This mutual authentication is typically performedby means of the IKEv2 protocol [rfc4306] which, in turn, relies on authentication mechanisms



such as the Extensible Authentication Protocol [rfc3748]. As result of a successful authentica-tion, IKEv2 allows the establishment of the so-called IPSec SA, i.e., parameters such as keysor algorithms to be used by AH or ESP. It is important to note that IKEv2 is an applicationlayer protocol managed by the ITS station security entity and not implemented by the IPv6security module.

The application of IPSec based access control to IPv6 communications is determined bythe security policy database (SPD), which contains a set of rules indicating what kind of IPv6traffic must be protected once a successful IPSec SA is established.

11.7.3 Example of network access control with EAP authentication sup-port

This section is intended to show an application example of the access control functionalityprovided by the IPv6 security module to implement an access control solution for restrictingthe access to the network resource.

Fig. 11.9 shows the considered scenario where a vehicle ITS station changes to a new pointof attachment (AR). Following the standard mobility procedures, the vehicle’s MR receivesa RA message from the AR containing the network prefix (NP) which is used by the MR toconfigure the new MR’s CoA (Care-of-Address). Next, the uniqueness of this CoA is checkedthrough the duplicate address detection (DAD) protocol.

Before the use of the new configured CoA for IPv6 communications (e.g., to inform thehome HA about the new vehicles’s location), the MR must get authenticated against the ARto gain access to the network. In fact, this policy could be enforced by the MR by configuringthe SPD in order to require the use of, for example, ESP protection for IPv6 communicationsbetween MR and AR. To establish the necessary IPSec SA, the IKEv2 protocol is executedbetween MR and AR where EAP is used as authentication mechanism. While the MR acts asEAP peer, the AR implements the EAP authenticator functionality. The EAP authenticatormay contact the home AAA server (acting as EAP server) through the AAA infrastructure.

Once the EAP authentication is successfully completed, the IKEv2 protocol negotiatesthe parameters of the IPSec SA (keys, algorithm to encipherment, keys, etc.). This IPSec SAis used to protect IPv6 packets transmitted between MR and AR through the ESP securityprotocol, thus satisfying the restriction on the AR for granting access to the network serviceto attached MRs.



InternetRoad Internal Network

Home ITS Station

AAAAAA (Proxy)

Visited ITS Station

EAP server

EAP peer

EAP authenticator

Figure 11.9: Vehicle ITS accessing to Internet through a roadside ITS station


CHAPTER 12

Module IPv6 multicasting

12.1 Overview

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to perform IPv6 multicast operations. This is ensured by the IPv6 multicastingmodule within the IPv6 protocol block. The IPv6 multicasting module performs the functionsrequired at the IPv6 layer for multicast communications, i.e. mechanisms for IPv6 multicastgroup advertisement, IPv6 multicast group membership and IPv6 multicast routing.

The protocol used to manage multicast group membership on an IPv6 link is the MulticastListener Discovery protocol known as MLD [rfc3810] and based on IGMPv3 (used in IPv4).It specifies separate behaviors for multicast address listeners (multicast hosts or routers thatlisten to multicast packets) and multicast routers. Multicast Listener Discovery allows nodesattached to an ITS station internal network to join the multicast group address bound tospecific applications requiring the transmission of IPv6 packets to multiple destinations. Themulticast sender could be located either in the ITS station internal network served by anotherITS station router, in a legacy access network or in the Internet. Specific mechanisms likeProxy MLD or either multicast distribution tree are used to deliver the multicast traffic fromthe source to the set of destinations.

This module is required for the distribution of IPv6 packets to a group of destinationslocated in a designated geographical area when IPv6 is combined with GeoNetworking ca-pabilities (see Section 10). Indeed, geographical areas could possibly mapped to a multicastgroup once other features are added in the ITS station management entity and at the ITSstation facilities. This has initially been proposed by the GeoNet European Project andis detailed in [GeoNet-D2.2] Section 11. The combination of IPv6 multicast and GeoNet-working as defined by the GeoNet project allows hosts attached to the ITS station internalnetwork to receive multicast packets sent to all ITS stations located in a specific geographicarea (e.g. hazardous event notifications). Though the addition of MLD could be consideredobvious, the mapping between multicast addresses and geographical areas remains a researchtopic. However, a static configuration can be used instead for well-known groups until dy-namic mechanisms are fully specified. IPv6 multicast over GeoNetworking is currently notyet adopted in any ISO or ETSI standard, since IPv6 GeoNetworking as defined by ETSIis only used to transmit IPv6 unicast packets over a link made of intermediate non-IP hopsused as forwarders .

101



Requirements to be contributed to ISO standardization have not yet been discussed.


CHAPTER 13

Module IPv4-IPv6 interoperability

13.1 Overview

In this Chapter we describe the procedures within the ITS station networking & transportlayer (SNT) to perform operations related to interoperability between IPv4 and IPv6. Thisis ensured by the IPv4-IPv6 interoperability module within the IPv6 protocol block. While allITS sub-systems required to support IPv6 for TCP/IP-based communications, IPv6 nodesdeployed in an ITS station may need to communicate with existing IPv4-only legacy ITSservices or non-ITS services that will continue to operate in the Internet for some years.In addition, as the IPv4 address depletion is driving a continuous but slow shift to IPv6connectivity, some access networks will still provide IPv4-only connectivity to the ITS station.The need for IPv4-IPv6 interoperability features is acknowledged in ISO 21210, but therequired features are not yet defined.

IPv6 access over IPv4 access networks for both continuous and non-continuous Internetconnectivity can be provided using DS-MIPv6, Softwire and OpenVPN. DS-MIPv6 [rfc5555]allows the ITS station to perform an IP mobility handover directly on IPv4-only access net-works. Alternatively, solutions such as Softwire [rfc5571] or OpenVPN may also be used toprovide the ITS station with IPv6 connectivity using a tunnel. The tunnel is build betweenthe ITS Station and a tunnel provider inside the network center. The tunnel is then availablefor the mobility mechanism to perform a handover on. Header and data compression mecha-nisms may be used on some tunnel solutions like Softwire in order to reduce the encapsulationoverhead.

Differents solutions are available in order to access IPv4-only services from the IPv6network of an ITS Station. Solutions can be offered at the network center level or at theservice level. At the network center level, NAT64 [rfc6146] is an easy to deploy solutionthat perform translation of IPv6 packets into IPv4 packets. This solution has no impacton the client nor the server side. But it has to be noted that NAT64 has an impact on thebehavior of some protocols like SIP for example, as address translation is only done in Layer-3header, not in application headers. At the service level, the obvious solution is to migrate thelegacy service into an IPv6-ready service. But this update of the service may have an impacton the quality of the existing service (untested new hardware or software, etc.). Solutionlike Application Level Gateway can be considered to achieve in a side deployment of IPv6compatibility of the service without impacting the existing service. This solution consists in

103


a dual-stack application-specific proxy like reverse HTTP proxy or SIP proxy which will bedeployed besides the existing service.

Deploying dual IPv6 and IPv4 stacks in ITS-S IPv6 LANs is not recommended as itwouldn’t scale to a large number of ITS-S IPv6 LAN due to the IPv4 address space depletion.IPv6 has been designed to address such IPv4 address shortcomings. In addition, features suchas network mobility support and other extensions are not supported in IPv4. It has to benoted that, as the ITS-S LAN will be IPv6-only, the hosts and applications connecting tothis network should be IPv6-compatible.


• ’ITS-S IPv6 routers’ shall provide IPv4/IPv6 transition mechanisms to transmit packetsover IPv4 networks between ’ITS-S IPv6 LANs’.

• IPv4/IPv6 transition mechanisms shall be offered so that ’ITS-S IPv6 LAN nodes’ cancommunicate with legacy IPv4-only nodes.


CHAPTER 14

MN-SAP: Interface between Management and Network entities

In this chapter we describe the procedures required for path and flow management (pathselection manager) between the SME and SNT for IPv6 networking i.e. the actions requestedfor the IPv6 protocol block to inform the SME about the current network conditions and forthe SME to provide routing policies to the IPv6 protocol block. The interaction is performedvia the MN-SAP by means of MN-COMMAND and MN-REQUEST function calls.

Four new primitives are proposed. First, two new primitives (MN-GET and MN-SET )are required for the SME to access to some of the parameters (N-Parameters) recorded in theexisting Management Information Base (MIB) of the IPv6 and TCP/UDP protocol blocks inthe SNT. The two other ones (MN-REQUEST and MN-COMMAND) are needed to instructthe IPv6 protocol block to route flows to a given path and correspond to the primitivesalready defined in ISO specifications for a network layer protocol block other than IPv6(i.e. FAST). However, the current ISO specification of MN-REQUEST and MN-COMMANDcommands do not fulfill our design requirements. We thus extend these primitives to transferthe necessary information between the SME and the IPv6, GeoNetworking and TCP/UDPprotocol blocks of the SNT. Six new MN-REQUEST commands (STAGeoNot, STATopoNot,STAServNot, PathNot, and PathMetricNot, FlowStatistics) and five new MN-COMMANDcommands (STAServDiscov, FlowClassificationRule, PathMNGT, FlowPolicy, FlowFeedback)are defined to accommodate our needs for determines on which path flows should be routed.

After a brief overview, the N-Parameter exchange (MN-SET and MN-GET ) is presentedin Section 14.2. Then, the parameters and primitives for path selection (MN-REQUEST andMN-COMMAND) are presented in Section 14.3.

Note that this study is based on year 2012 versions of the ISO Standards and that thestandards constantly evolve. As a result, primitives and parameters of the MN-SAP mayhave changed at time of reading.

14.1 Overview

The interaction between the ITS station management entity (SME) and the ITS station net-working & transport layer (SNT) for IPv6 networking is illustrated on Figure 14.1. From theSNT, the network status is notified to the SME so that availability of new and existing pathscan be determined by the SME. From the SME, instructions are provided to the SNT where

105


they are interpreted by an adaptation agent that translates and passes these instructions tothe appropriate module (on the figure, a set of protocols for ease of undertanding).


GeoNetworking

IP

TransportTCP UDP

NEMO

NDP

IP Filter

Routing

GeoNetworking

MN-SAP

MIB in Network &

Transport layer

MIB for TCP [rfc4022]

MIB for UDP [rfc4113]

MIB for IP [rfc4293]

MIB for IP tunnel [rfc4087]

MIB for MIPv6 [rfc4295]

MIB for NEMO [rfc5488]

MIB for GeoNetworking [TBD]Adaptation

Entity

Adaptation

Agent

Path Selection Manager

ITS Local

Network

Other

Protocols

MN-GET

MN-SET

MN-COMMAND

N-parameter

MN-REQUEST

Figure 14.1: Interface Between the Management Entity and the Network Layer

The notification of the network status has two communication modes. The first one isissued from the SNT to the SME to notify an event happened (MN-REQUEST). The otherone is issued by the SME to the SNT to read the values contained in the MIB (definedas N-Parameter in ISO specifications - see Section 14.2.3) updated regularly by the SNT(MN-GET).

There are also two modes for the instructions, both of them are issued by the SME tothe SNT. First type of instruction is translated directly into an action in the SNT (MN-COMMAND). The other one sets N-Parameter values that define the default behavior of theSNT (MN-SET).

14.2 N-Parameter exchange

14.2.1 MN-SET command

MN-GET and MN-SET are new commands that provide means for the SME to accessthe N-Parameters of the SNT. Some of N-Parameters in the SNT have been specified in[rfc4022, rfc4113, rfc4293, rfc4087, rfc4295, rfc5488]. We define four new primitives for MN-SET and MN-GET as follows: MN-SET.request, MN-SET.confirm, MN-GET.request, MN-GET.confirm



14.2.1.1 MN-SET.request

The primitive MN-SET.request allows the SME to set N-Parameters. The parameters of theMN-SAP primitive MN-SET.request are as follows:

MN-SET.request (

CommandRef,N-Param.OID,N-Param.Value

)

On receipt of the primitive MN-SET.request the selected parameters shall be set at the SNTif applicable.

Name Type DescriptionCommandRef Integer Unique cyclic reference number of command.N-Param.OID MIB object Object identifier of the N-Parameter. The Object

identifier follows the specification of Structure ofManagement Information Version 2 (SMIv2) [rfc2578]

N-Param.Value — Value of the N-Parameter.

Table 14.1: MN-SET.request parameters

14.2.1.2 MN-SET.confirm

The primitive MN-SET.confirm reports the result of a previous MN-SET.request. The pa-rameters of the primitive MN-SET.confirm are as follows:

MN-SET.confirm (

CommandRef,N-Param.OID,Errors.errStatus

)

This primitive is the response to MN-SET.request with the requested N-Parameter valuesin case the status is “success”. Otherwise, an error code is returned in the status field.Possible error status includes “invalid N-Parameter object identifier” and “attempt to readfrom write-only N-Parameter”. The error codes are the same as the ones used for MI-SETin [ISO-24102-2].

14.2.2 MN-GET command

14.2.2.1 MN-GET.request

The primitive MN-GET.request allows the SME to request the reporting of N-Parametervalues. The parameters of the primitive MN-GET.request are as follows:

MN-GET.request (




identifier follows the specification of SMIv2 [rfc2578]Errors.errStatus One octet

integerReturn error code. See details in [ISO-24102-2]

Table 14.2: MN-SET.confirm parameters

CommandRef,N-Param.OID

)

This primitive is generated by the SME when N-Parameter values shall be retrieved. Onreceipt of the primitive MN-GET.request N-Parameters shall be reported to the SME.


identifier follows the specification of SMIv2 [rfc2578]

Table 14.3: MN-GET.request parameters

14.2.2.2 MN-GET.confirm

The primitive MN-GET.confirm reports N-Parameter values to the SME. The parametersof the primitive MN-GET.confirm are as follows:

MN-GET.confirm (

CommandRef,N-Param.OID,N-Param.ValueErrors.errStatus

)

This primitive is the response to MN-GET.request. In the case of Errors.errStatus = “suc-cess”, N-Param.Value is set to the value of the requested parameter. Possible error status in-cludes “invalid N-Parameter object identifier” and “attempt to write to read-only N-Parametervalue”. The error code are the same as the ones defined for MI-SET in [ISO-24102-2].

14.2.3 N-Parameter for IPv6

We define N-Parameters in the ITS station networking & transport layer (SNT) as a set ofvirtual databases. This complies with I-Parameters defined in the access technologies layer[ISO-24102-2]. The SNT update N-Parameter according to network status change. Also, N-Parameter defines default behavior of the SNT. MN-GET and MN-SET explained in Section14.2.1 provide means for the SME to read and write the values of N-Parameter.




identifier follows the specification of SMIv2 [rfc2578]N-Param.Value — Value of the N-Parameter.Errors.errStatus One octet

integerReturn error code. See details in [ISO-24102-2]

Table 14.4: MN-GET.confirm parameter description

In IPv6, some of the necessary protocols already have a virtual database called Man-agement Information Base (MIB) defined by IETF. Objects in the MIB are defined usinga subset of Abstract Syntax Notation One (ASN.1) [ITU-T-X.680-ASN1:2002] called SMIv2[rfc2578]. MIB is often used in Simple Network Management Protocol (SNMP)[rfc3411], theterm is also used more generically in contexts such as in Open Systems Interconnection (OSI)network management model.

MIBs are already defined for most of the protocols of the SNT. The MIB for TransmissionControl Protocol (TCP) is specified in [rfc4022] and in [rfc4113] for User Datagram Protocol(UDP). For IP, MIBs for IP [rfc4293], for IP tunnel [rfc4087], for Mobile IPv6 [rfc4295] andfor NEMO [rfc5488] have been defined by the IETF, as well. No MIB is defined yet for theGeoNetworking protocol. Section 14.2.4 presents a attempt of the definition of the necessaryobjects.

Note that a MIB must also be defined in the SME in the ITS Station Architecture, howeverit won’t serve the same purpose and should not duplicate the N-Parameters contained in theSNT. The N-Parameters in the SNT should indeed be considered as the parameters thatdefine the default behavior of SNT. On the other hand, the MIB in the SME would be usedto respond to the requests to read and write the parameters (i.e. to be used to respond tothe SNMP request from the other node).

When there are common parameters in the SME and the SNT, the value of an objectof MIB in the SME are redirected to the corresponding N-Parameter in the network layer(i.e. symbolic links) rather than duplicating the value in SME and SNT . When SME isrequested to read/write to such parameters, it redirects the request to the N-Parameter usingMN-GET and MN-SET (defined in Section 14.2.1) via the MN-SAP.

14.2.4 N-Parameters for GeoNetworking

We classify the parameters into the basic setting of GeoNetworking and five main functionssuch as Communication Interface (CI), Location Table (LT), Beaconing, Location Service(LS) and Forwarding. Table 14.2 shows all the parameters for GeoNetworking. We keep thestatistics table for GeoNetworking for future work (Such statistics for IP are defined in MIBfor IP as IP statistics table in [rfc4293]). All the parameters should be accessible from themanagement entity by MN −GET and MN − SET with read and write permission.



Parameter DescriptionBasic GeoCapability This object indicates whether the GeoNetworking

function is enabled.GeoNodeID This object indicates GN_ADDR in

[ETSI-TS-102-636-4-1] that could be updated forprivacy reasons (i.e. pseudonym).

CI GeoIpInterfaceIndex The index to uniquely identify the interface between

GeoNetworking and IP.GeoAccess

InterfaceIndexThe index to uniquely identify the interface betweenGeoNetworking and Access. ex. egress interface.

LocationTableLifeT ime This object indicates the default lifetime of the entry inthe location table.

LT LocationTableMaxNode This object indicates the maximum number of the nodesstoring in the location table.

LocationTableEntry This object indicates the entries of location table.

Beacon BeaconInterval This object indicates the default time interval of

beacons.BeaconHopLimit This object indicates the default hop limit of beacons.

LocationServiceType The object indicates the default type of Location Service(ex. flooding, request-reply, etc.)

LS LocationServiceHopLimit

This object indicates default hop limit of locationservice message.

LocationServiceRetransT imer

The objects indicates the default time interval to resendthe request of Location Service.

Forw

arding StoreForwardLifeT ime The object indicates the lifetime of storing packets,

when the node is out of destination area.StoreForwardMaxSize This object indicates the maximum size of packet stored

in the node for store and forward.TrafficHopLimit This object indicates default hop limit of traffic packet.

Others PositionV ector The object indicates the position vector of the ITS-S.

GeoDestination The object indicates the mapping between group ID andgeographic destination area.

Figure 14.2: N-Parameters for GeoNetworking

GeoCapability and GeoNodeID are defined as basic setting. The management entitydetermines whether the GeoNetworking function is enabled or not using GeoEnableStatus.Also, it can enable and disable the GeoNetworking function usingGeoEnableStatus. GeoNodeIDindicates the GeoNetworking ID (GN_ADDR in [ETSI-TS-102-636-4-1]) used in the ITSstation. For preventing the location privacy issue, the management entity may changethe GeoNetworking ID in certain interval so that the node uses the ID as a pseudonym.GeoNodeID provides a means to change the GeoNetworking ID via MIBset.

GeoAccessInterfaceIndex and GeoIpInterfaceIndex are defined as CI parameters.GeoAccessInterfaceIndex indicates the index of the egress interface of GeoNetworking andGeoIpInterfaceIndex indicates the index of virtual interface between GeoNetworking andIP. The former object is mandatory for all the GeoNetworking nodes because all of themhave the egress interface. On the other hand, later object is used only in IPv6 GeoNetwork-ing, when GeoNetworking gives the packet to the IP layer or vice versa. These objects only



provides the interface index, however the management entity can find corresponding locatorand identifier (i.e. IP address or prefix information) of the ITS Station by the interface indexusing MIB for IP.

LocationTableLifeT ime, LocationTableMaxNode and LocationTableEntry are definedas LT parameters. LocationTableLifeT ime indicates the default lifetime of the LocationTable entries. When neighbor nodes are moving fast and are organizing very dynamic net-work topologies, a neighbor ITS Station position kept as a Location Table entry cannotbe fresh for long time. Thus the lifetime of Location Table should be configured shorter.LocationTableMaxNode indicates the maximum number of nodes stored in the LocationTable. In a traffic jam situation, many neighbor ITS Station position stored in the LocationTable amplifies the calculation time of the next hop GeoNetworking node. The managemententity can set proper number of nodes in Location Table to avoid performance degrada-tion. LocationTableEntry indicates the entries of Location Table. The management entityget the position information of neighbor GeoNetworking nodes including GeoNetworking ID,latitude, longitude, altitude, speed, heading and lifetime.

BeaconInterval andBeaconHopLimit are defined as beacon parameters. BeaconIntervalindicates the time interval between beacons. In the GeoNetworking layer, the position of theITS Station should be updated frequently because the Location Table entry in the neighbornode cannot be fresh. On the other hand, in case of traffic jam, the frequent updates ofthe Location Table entries are not necessary, in contrary, the frequent beacons from manyGeoNetworking node cause congestion of traffic. Thus in low-speed situation, longer timeinterval between beacons is favorable. BeaconHopLimit indicates the hop limit of the bea-cons. Normally, the hop limit is set as 1, however multi-hop beaconing is considered as anadvanced feature of GeoNetworking. Multi-hop beaconing allows a GeoNetworking node toget the position of neighbors several hops away. In packet transmission, the node can avoidto send Location Service request when it has the position of the destination node in LocationTable. Thus multi-hop may improve the delay by increasing the possibility to avoid Loca-tion Service signaling. There is a trade-off between the delay and network traffic congestionbecause of beacon flooding.

LocationServiceType, LocationServiceHopLimit and LocationServiceRetransT imerare defined as Location Service parameters. LocationServiceType indicates the defaultLocation Service type including the flooding and request-reply signaling. The manage-ment entity can decide how to get the destination position depending of the situation.LocationServiceHopLimit indicates the default hop limit of Location Service. Normally,the value is set as 255. LocationServiceRetransT imer indicates the default time interval ofresending Location Service request when the node has no Location Service reply.

StoreForwardingLifeT ime, StoreForwardingMaxSize and TrafficHopLimit are de-fined as forwarding parameters, . StoreForwardingLifeT ime indicates the lifetime of storedpackets when the destination node is not its neighbor. The stored packets can be deliveredto a longer distance with longer lifetime of storing packets. Thus it increases possibility toreach the destination, however there are a trade-off between memory for storing packets andcalculation time in the forwarding table. StoreForwardingMaxSize indicates the maxi-mum total size of stored packets. TrafficHopLimit indicates the default hop limit of trafficpacket.

PositionV ector andGeoDestination are defined as the other parameters. PositionV ectorindicates the position vector of the nodes including latitude, longitude, altitude, speed, head-ing and lifetime. GeoDestination indicates the mapping between multicast address and thegeographical destination area (GeoDestination) defined in [ETSI-EN-302-931].



14.3 Parameters and primitives for path and flow management

14.3.1 MN-REQUEST and MN-COMMAND

In this section, we propose new MN-REQUEST commands and MN-COMMAND commandsthat are required for path and flow management.

The naming convention for MN-SAP primitives is as follows:

• Station → abbreviated as “STA”

• Notification → abbreviated as “Not”

Table 14.5 presents theMN-REQUEST commands defined for the SNT to notify the SMEabout the network status, depending on type of information. A more detailed description isprovided in the following sub sections.

Command name DescriptionSTAGeoNot Notification of geographic information of an ITS station.STATopoNot Notification of topological locator of an ITS station.STAServNot Notification of service of an ITS stationPathNot Notification of status of a path

PathMetricNot Notification of network metric of a pathFlowStatistics Provide network flow statistics.

Table 14.5: New MN-REQUESTs

Table 14.6 presents the MN-COMMAND commands defined for the SME to instruct theSNT. A more detailed description is provided in the following sub sections.

COMMAND name DescriptionPathMNGT Command for managing a path

FlowClassificationRule Attribute an identifier to each packet that is output or forwardedby ITS Station.

FlowPolicy Set flow policy for the currently available paths in local andneighbor ITS stations.

FlowFeedback Request flow statistics from the network.STAServDiscov Discover an ITS station that can provide a service

Table 14.6: New MN-COMMANDs

Figure 14.3 shows the information flow between the path selection manager in the SMEand the horizontal layers. Details are provided in Chapter 4.

14.3.2 MN-REQUEST STAGeoNot

MN-Request.STATopoNot shall be used by the SNT to notify the geographical position in-formation of an ITS station to the SME. Table 14.7 shows the parameters of STATopoNot .

.



Flow

Flow req & Flow stat

Network &Transport

Management



table

Network &Transport

Facilities

AccessMI-REQUEST

MF-REQUEST

MN-COMMAND

MN-REQUEST

ITS-S information

Path Information

Information

MI-SAP

MF-SAP

MN-SAPGeographic Position

Topological Information

Path Status

Interface

Flow requirement list

ITS-S Basic info

SAP

MN-SAP

Path Infomation

Flow Classification Rule

Network Metric

ITS-S Information

Service

STATopoNot

STAGeoNot

PathNot

Event

PathMNG

FlowClassRule

ITS-S-Appl-Reg

PathMetricNot

STAServDiscov

STAServNot

Path and Flow Management

MI-SAP

MF-SAP

MN-SAP

SAP Function parameter

MF-SAPMN-

SAP

[ISO_24102]

Flow StatisticsFlowStatNot

[ISO_24102]

Flow PolicyFlowPolicy

FlowMonitor Flow Statistics


table

Flow Policy table

Flow statistics table



Figure 14.3: Cross-layer information flow for path and flow management

14.3.3 MN-REQUEST STATopoNot

MN-Request.STATopoNot shall be used by the SNT to notify the topological locator infor-mation of an ITS station to the SME. Table 14.8 describes parameters of STATopoNot .

14.3.4 MN-REQUEST STAServNot

MN-Request.STAServNot shall be used by the SNT to notify the service information of anITS station to the SME. Table 14.9 shows the parameters of STAServNot .



ASN.1 Type Valid Range Description

MN-Request.STAGeoNot — Notification of geographic information of an ITS StationSTAGeoNot.ITS-scuId ITS-scuId ITS-SCU-ID of an ITS station at the geographical

position reported in the request.STAGeoNot.latitude 32 bit signed

integerWGS-84 latitude of the ITS station expressed in 1/10micro degree.

STAGeoNot.longitude 32 bit signedinteger

WGS-84 longitude of the ITS station expressed in 1/10micro degree.

STAGeoNot.altitude 16 bit signedinteger

Altitude of the ITS station expressed in signed units of1 meter.

STAGeoNot.speed 16 bit signedinteger

Speed of the ITS station expressed in signed units of0.01 meter per second.

STAGeoNot.heading 16 bit unsignedinteger

Heading of the ITS station expressed in unsigned unitsof 0.1 degrees from North.

STAGeoNot.accuracy 16 bit unsignedinteger

Accuracy indicator of the geographical position of theITS station

STAGeoNot.timestamp UTC The time when the corresponding geographical positionis recorded in units of seconds.

STAGeoNot.lifetime 16 bit unsignedinteger

(Optional) The expiration time of the correspondinggeographical position entry in units of seconds.

Table 14.7: Parameters of MN-REQUEST “STAGeoNot”


MN-Request.STATopoNot — Notification of the network topology locator of an ITSstation

STATopoNot.ITS-scuId ITS-scuId ITS-SCU-ID of the ITS station that has the networktopology locator reported in the request.

STATopoNot.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it isthe network part (first 64bits) of an IP address thatindicates the location of the node in the networktopology.

Table 14.8: Parameters of MN-REQUEST “STATopoNot”

14.3.5 MN-REQUEST PathNot

MN-Request.PathNot shall be used by the SNT to notify the status of a path to the SME.Table 14.10 shows the parameters of PathNot .




MN-Request.STAServNot — Notification of the service of an ITS stationSTAServNot.ITS-scuId ITS-scuId ITS-SCU-ID of the ITS station that provides the service

reported in the request.STAServNot.service 64 bit flags The services that the ITS-S can provide, e.g.

• DNS server • Multicast Listener• Location registration • Qos• Gateway • TBD• DHCP

Table 14.9: Parameters of MN-REQUEST “STAServNot”


MN-Request.pathNot — Notification of status of a pathPathNot.localCIID 64 bits permanent, ex. EUI-64 or generated with the way in

ISO21218PathNot.remoteCIID 64 bits dynamic, ex. EUI-64 of remote CI (last hop) or a serial

number according to the access technology) (Can bedynamic or static ISO21218)

PathNot.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it is thenetwork part (first 64bits) of an IP address that indicatesthe location of the node in the network topology.

PathNot.nexthop ITS-scuId ITS-SCU-ID of an ITS station on the path that acts as aborder router when packet goes beyond the networkmanaged by a local routing protocol. (ex. MR or AR in thecase of the path from the vehicle ITS Station)

PathNot.anchor ITS-scuId ITS-SCU-ID of an ITS station that provides Locatorregistration function to ITS-S.

PathNot.reachability 16 bit flags Network topology distance indicator from the CI• on-link • ITS domain• Local Network • Global Network• Extended Local • TBD

PathNot.capabilities 64 bit flags Capabilities offered on the path, e.g.• Reverse reachability for host • 1-to-n for group• Session continuity for host • 1-to-n for GeoArea• Reverse reachability for network • QoS• Session continuity for network • TBD

PathNot.status 16 bit flags Status of the path.0: not available 2: ready to be used 4: going to up1: being used 3: potentially ready 5: going to down

Table 14.10: Parameters of MN-REQUEST “PathNot”

14.3.6 MN-REQUEST PathMetricNot

MN-Request.PathMetricNot shall be used by the SNT to notify path metrics to the SME.Table 14.11 shows the parameters of MN-Request.PathMetricNot .




MN-Request.pathMetricNot — Notification of network metric of a pathPathMetricNot.Payload 0 - 65536 Size of payload for a packet using the path.PathMetricNot.Delay 0 - 65536 A trip time that the path has, and actual round trip

time to reach to the node in the destination scopePathMetricNot.Hop 0 - 255 Number of hops to reach to the destination.

Table 14.11: Parameters of MN-REQUEST “PathMetricNot”

14.3.7 MN-REQUEST FlowStatistics

MN-Request.FlowStatistics shall be used by the SNT to notify network statistics to the SME.Table 14.12 shows the parameters of FlowStatistics.


MN-Request.flowStatistics — Provide network from statistic informations.FlowStatistics.commMode node/group/geoAreaCommunication mode of the reported

connection.FlowStatistics.destination Node ID/group

ID/geoArea IDDestination of the reported connection.

FlowStatistics.source ITS StationNode ID

Source of the reported connection.

FlowStatistics.protocol Protocol ID Network protocol ID of the reported connectionFlowStatistics.protocolInfo 1024 bit blob Protocol-specific informationFlowStatistics.flowID Flow ID Classification currently issued for traffic from

this connectionFlowStatistics.pathID Path ID Path currently used for traffic from this

connectionFlowStatistics.datarate 32 bit unsigned

integerDatarate of this connection in bits/seconds

FlowStatistics.pps 16 bit unsignedinteger

Packets per seconds of this connection

Table 14.12: Parameters of MN-REQUEST “FlowStatistics”

14.3.8 MN-COMMAND PathMNGT

MN-Command.PathMNGT shall be used by the SME to request management of a path, thatincludes establishment, removal of a path or change of the path parameters (the locator, thenexthop and the anchor, etc.). Table 14.13 shows the parameters of PathMNGT .

14.3.9 MN-COMMAND FlowClassificationRule

MN-Command.FlowClassificationRule" shall be used by the SME to define classification rulesto be applied in the ITS station. Table 14.14 shows the parameters of FlowClassificationRule.

14.3.10 MN-COMMAND FlowPolicy

MN-Command.FlowPolicy shall be used by the SME to request enforcement of flow policyin the local ITS station. Table 14.15 shows the parameters of FlowPolicy .




MN-Command.pathMNGT — Notification of status of a pathPathMNGT.linkID Link-ID of CI Link ID of the CI where the path starts fromPathMNGT.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it is

the network part (first 64bits) of an IP address thatindicates the location of the node in the networktopology.

PathMNGT.nexthop ITS-scuId ITS-SCU-ID of an ITS station on the path that is aborder between wireless network and wired network.(ex. MR or AR in the case of the path from the vehicleITS Station)

PathMNGT.anchor ITS-scuId ITS-SCU-ID of an ITS station that provides Locatorregistration function to local ITS-S.

PathMNGT.reachability 16 bit flags Topological distance indicator from the CI• on-link • ITS domain• Local Network • Global Network• Extended Local • TBD

Table 14.13: Parameters of MN-COMMAND “PathMNGT”


MN-Command.flowClassificationRule — Management of flow classification.FlowClassificationRule.commMode node/group/

geoAreaCommunication mode used by the packet.

FlowClassificationRule.destination Node ID /group ID/geoArea ID

Destination of the packet.

FlowClassificationRule.source ITS stationNode ID

Source of the packet.

FlowClassificationRule.protocol Protocol ID Network protocol IDFlowClassificationRule.protocolInfo 1024 bit blob Protocol-specific informationFlowClassificationRule.flowID Flow ID Classification issued by this rule

Table 14.14: Parameters of MN-COMMAND “FlowClassificationRule”

14.3.11 MN-COMMAND FlowFeedback

MN-Command.FlowFeedback shall be used by the SME to request statistics from the SNT.Table 14.16 shows the parameters of FlowFeedback .

14.3.12 MN-COMMAND STAServDiscov

MN-Command.STAServDiscov shall be used by the SME to request discovery of services.Table 14.17 shows the parameters of STAServDiscov .

For example, in the IPv6 protocol block of the SNT, the service discovery triggers RouterSolicitation, Neighbor Solicitation in NDP to discover new ARs and new neighbors whenservice field is specified as discovery of “access” and “neighbor”. Or Anchor service discoveryis specified in service field of ServDiscov, it is translated into Dynamic Home Agent AddressDiscovery request in NEMO. The cycle of the path selection manager returns to the candidatepath calculation because another candidate path may appears as a result of service discovery




MN-Command.flowPolicy — Management of the flow policy table.FlowPolicy.action add / modify /

del / flushAction to perform on flow policies

FlowPolicy.flowID Flow ID An identifier to distinguish a flow. Flow ID is theclassification issued on each packet by FlowClassification Rules.

FlowPolicy.pathID Path ID unique ID to identify a pathFlowPolicy.priority 0 - 255 priority of the policy. The higher it is the more the rule

is prioritized.

Table 14.15: Parameters of MN-COMMAND “FlowPolicy”


MN-Command.flowFeedback — Request for statistic information.

Table 14.16: Parameters of MN-COMMAND “FlowFeedback”

(e.g. discovery of new access services (ARs) or anchor services).


MN-Command.sTAServDiscov — Discover an ITS Station that can provide aservice

STAServDiscov.service 64 bits flags The services that the ITS-S can provide to selfITS-S.• DNS server • Multicast Listener• Location registration • Qos• Gateway • TBD• DHCP

Table 14.17: Parameters of MN-COMMAND “STAServDiscov”


CHAPTER 15

SN-SAP: Interface between Networking & Transport Layer and SecurityEntity

15.1 Overview

Fig. 15.1 shows the message flow involving the SN-SAP whenever messages pass the SNTfor security services. The SSE acts like a layer inside the SNT, i.e., it is called during theprocessing of messages traversing the SNT. The security entity does not act as a layer aboveor below the SNT, i.e., interactions with facilities and access layers are achieved via otherSAPs.

Figure 15.1: Relation with the ITS station security entity through SN-SAP

15.2 Service Interfaces of the SN-SAP

We define two service interfaces for the SN-SAP:

119


Table 15.1: Description of SN-Request.No.SN-Request.No SN-Request Name Description0 – Reserved for future use.1 HashingReq Request hashing.2 SigningReq Request signing.3 VerificationReq Request verification.4 EncryptionReq Request encryption.5 DecryptionReq Request decryption.6 PseuReq Request pseudonym bits.7 ... 224 – Reserved for other use.225 ... 255 – Reserved for private non-standardized use.

• The SN-COMMAND service is a generic command executed from the security entityto the networking & transport layer.

• The SN-REQUEST service is a generic command executed from the networking &transport layer to the security entity.

As of writing, details of the SN-COMMAND service are not presented. We only detail theSN-REQUEST service. The SN-REQUEST service from the networking & transport layerto the security entity is mainly used to request the atomic security operations, i.e., hashing,signing/verification, and encryption/decryption and to obtain an arbitrary bit string (i.e., bitsgenerated by the pseudonym service). The SN-REQUEST service has two service primitives,SN-REQUEST.request and SN-REQUEST.confirm, as:

SN-REQUEST.request(CommandRef, SN-Request)SN-REQUEST.confirm(CommandRef, SN-ReqConfirm, ErrStatus)

SN-REQUEST.request is sent from the networking & transport layer to the security entityfor executing a specific command, whereas SN-REQUEST.confirm is sent from the security en-tity to the networking & transport layer as a corresponding response to SN-REQUEST.request.

15.3 SN-SAP Parameters

Parameters of SN-REQUEST.request and SN-REQUEST.confirm are as follows:

• CommandRef is the cyclic number used as an identifier of SN-REQUEST.request, also to beused in SN-REQUEST.confirm in order to refer to the corresponding SN-REQUEST.request.

• SN-Request is the details of request from the networking & transport layer.

• SN-ReqConfirm is the optional confirmation data from the security entity.

• ErrStatus is the error status.

SN-Request consists of the reference number (SN-Request.No) and the value (SN-Request.Value).SN-Request.Value contains optional and specific values depending on SN-Request.No asshown in Table 15.3.


APPENDIX A

Candidate technologies for access control in ITS

Several network access technologies are candidate solutions to be used in vehicular environ-ments. The most relevant one is the IEEE 802.11 wireless family. This technology is usuallyincluded in Vehicular Adhoc Networks (VANETs) designs to deploy cooperative services be-tween vehicles (V2V) such as traffic safety applications (also known as collision avoidance). InV2I scenarios, the cellular UMTS communication system, and its LTE evolution are consid-ered the most appropriate to provide Internet connectivity to vehicles. A possible limitationto the use of cellular technologies is the radio coverage, especially in rural areas or in othermotorways isolated from urban centers.

It is thus obvious that the mechanism used for access control needs to be performedacross different wireless network access technologies. This situation motivates researchers todefine a unique solution independent of the underlying wireless technology. In fact, nowadayseach wireless technology defines its own mechanisms to perform the authentication and keydistribution processes. Similarly to the adoption of IP as a tool to homogenize the communi-cations performed over different technologies in future mobile networks, it seems reasonableto adopt a universal access control solution that is agnostic to the particular network accesstechnology.

In this regard, the standardization body Internet Engineering Task Force (IETF) hasdesigned the Extensible Authentication Protocol (EAP) [rfc3748]. EAP exhibits some inter-esting features that clearly favour its adoption in future mobile networks like, for example,VANETs. On the one hand, the protocol has been conceived to be independent of the un-derlying technology used to transport the protocol messages. This independence is of vitalimportance for future mobile networks since it allows the authentication and key distributionprocess to be done through different link-layer technologies or other IP-based protocols usedin network access control such as PANA [rfc5191] or IKEv2 [rfc4306]. On the other hand,EAP allows for easy integration with the already deployed Authentication, Authorization andAccounting (AAA) infrastructures [rfc2903], which provide trust between domains. Thanks tothis feature, network operators that have deployed an AAA infrastructure in their domains,can easily deploy EAP as a solution to control the authentication process.

Moreover, instead of proposing a specific authentication mechanism, EAP defines a flex-ible framework that permits different types of authentication mechanisms through the so-called EAP methods. EAP methods constitute the mechanism to extend the functionalityof EAP without modifying the protocol itself. Specifically, as observed in Fig. A.1, EAP

121


Figure A.1: EAP Authentication Framework

methods are performed between an EAP peer and an EAP server through an EAP authenti-cator which merely sends authentication information back and forth between the EAP peerand the EAP server. Whereas the EAP peer is co-located with the mobile node, the EAPauthenticator is commonly placed on the so-called Network Access Server (NAS), which is incharge of interfacing with the peer to carry out the authentication (e.g., an access point oran access router). The EAP server can be placed with the authenticator (standalone mode)or co-located with an AAA server (pass-through mode).

An EAP lower-layer is used to transport the EAP packets between the EAP peer andthe EAP authenticator and an AAA protocol is used for the same purpose between the EAPauthenticator and the EAP server in the pass-through mode. On the one hand, existing EAPlower-layers are IEEE 802.1X, IEEE 802.11, IEEE 802.16e, PANA and IKEv2. On the other,RADIUS and Diameter are the most well-known AAA protocols.

Apart from this flexibility, some EAP methods not only provide authentication, but arealso able to generate key material for posterior use once the EAP authentication has beensuccessfully completed. In particular, as depicted in Fig. A.1, some of this cryptographicmaterial like the Master Session Key (MSK) and Extended Master Session Key (EMSK)can be used to protect the wireless link between the mobile user and the authenticator. Todo so, it is first necessary to perform a key distribution process in order to provide somecryptographic material to the peer and authenticator which allows the execution of a securityassociation protocol (e.g., 4-way handshake in IEEE 802.11 at link-layer or IKEv2 at IP-layer)that will protect the wireless communication.

All these properties make EAP a promising authentication framework, in general, forfuture heterogeneous wireless networks and, in particular, for vehicular networks. In fact,different standardization organizations have used EAP when developing wireless technologiesand protocols for network access control. For example, in WiFi-based WLAN networks, theIEEE 802.11i specification defines an authentication system that uses EAP as a mechanism toverify the user’s identity. Similarly, for WMAN networks using the WiMAX technology, theIEEE 802.16e specification relies on EAP to develop an integrated authentication mechanism.Also, the use of EAP at application layer has been considered by the IETF ApplicationBridging for Federated Access Beyond Web (ABFAB) working group to propose a federatedauthentication and authorization architecture to control the access to network services (weband non-web services) by using a single user credential.


APPENDIX B

Terminology

Term Definition ReferenceCare-of Address ’IPv6 address’ associated with a mobile

node while attached on a ’foreign IPv6link’

[ISO-21210]

egress IPv6 interface interface of an MR attached to the’home IPv6 link’ if the ’IPv6 mobilerouter’ is at home, or attached to a’foreign IPv6 link’ if the ’IPv6 mobilerouter’ is in a foreign network

[rfc3753][ISO-21210]

external IPv6 interface ’IPv6 interface’ of an ’ITS-S IPv6router’ in an ITS station used to con-nect to another ITS station or the In-ternet

[ISO-21210]

foreign IPv6 link ’IPv6 link’ other than the mobile node’s’home IPv6 link’

[ISO-21210]

global IPv6 address ’IPv6 address’ corresponding to ’GlobalUnicast Addresses’

[rfc4291][ISO-21210]

home address (HoA) ’IPv6 address’ assigned to a mobilenode, used as the permanent address ofthe mobile node

[rfc3753][ISO-21210]

home IPv6 link ’IPv6 link’ on which a mobile node’s’home IPv6 prefix’ is defined

[ISO-21210]

home IPv6 prefix ’IPv6 prefix’ corresponding to a mobilenode’s ’home address’

[ISO-21210]

home ITS-S IPv6 LAN ’ITS-S IPv6 LAN’ providing Internetreachability functions to ’mobile ITS-SIPv6 LANs’

[ISO-21210]

ingress IPv6 interface interface of an MR attached to a ’IPv6link’ inside the ’IPv6 moblie network’

[rfc3753][ISO-21210]

IPv6 subnet Logical group of connected networknodes. Nodes in an ’IPv6 subnet’ sharea common network prefix

[rfc3753][ISO-21210]

continued on next page

123


Term Definition ReferenceIPv6 Access Network (AN) ’IP network which includes one or more

Access Network Routers’[rfc3753][ISO-21210]

IPv6 access router (AR) ’Access Network Router residing on theedge of an Access Network and con-nected to one or more Access Points’

[rfc3753][ISO-21210]

IPv6 address IPv6-layer identifier for an interface ora set of interfaces

[rfc2460][ISO-21210]

IPv6 home agent (HA) ’IPv6 router’ on a mobile node’s ’homeIPv6 link’ with which the mobile node(MN) has registered its current Care-ofAddress.

[rfc3753][ISO-21210]

IPv6 host any ’IPv6 node’ that is not a ’IPv6router’

[rfc2460][ISO-21210]

IPv6 interface Node’s attachment to an ’IPv6 link’. [rfc2460][ISO-21210]

IPv6 link Communication facility or medium overwhich nodes can communicate at thelink layer, i.e. the layer immediatelybelow IPv6.

[rfc2460][ISO-21210]

IPv6 mobile network Entire network, moving as a unit, whichdynamically changes its point of attach-ment to the Internet and thus its reach-ability in the topology

[rfc3753][ISO-21210]

IPv6 mobile router (MR) ’IPv6 router’ capable of changing itspoint of attachment to the network,moving from one ’IPv6 link’ to another’IPv6 link’.

[rfc3753] and[ISO-21210]

IPv6 node Device that implements IPv6 [rfc2460] and[ISO-21210]

IPv6 prefix Bit string that consists of some numberof initial bits of an ’IPv6 address’

[rfc3753] and[ISO-21210]

IPv6 router ’IPv6 node’ that forwards IPv6 packetsnot explicitly IPv6 addressed to itself

[rfc2460] and[ISO-21210]

ITS-S IPv6 access router ’IPv6 router’ implementing communi-cation functions of an ITS station andoffering access to ’mobile ITS-S IPv6LAN’s.

[ISO-21210]

ITS-S IPv6 border router IPv6 router implementing communica-tion functions of an ITS station andconnecting ’ITS-S IPv6 LANs’ to theInternet and other networks.

[ISO-21210]

ITS-S IPv6 home agent ’IPv6 home agent’ implementing com-munication functions of an ITS stationand maintaining access to ’mobile ITS-S IPv6 LAN’s.

[ISO-21210]

ITS-S IPv6 host ’IPv6 host’ implementing non-routingcapabilities of an ITS station

[ISO-21210]

ITS-S IPv6 LAN IPv6 LAN composed of one or moreIPv6 subnets comprising one or moreITS station(s) and 0 or more legacyIPv6 node(s) deployed in an ITS sub-system.

[ISO-21210]




Term Definition ReferenceITS-S IPv6 LAN interface ’IPv6 interface’ of an ’IPv6 node’ in an

ITS station used to connect to the ’ITS-S IPv6 LAN’

[ISO-21210]

ITS-S IPv6 LAN node a node on an ’ITS-S IPv6 LAN’ [ISO-21210]ITS-S IPv6 mobile router ’IPv6 router’ implementing communi-

cation functions of an ITS station anddeployed in a ’mobile ITS-S IPv6 LAN’.

[ISO-21210]

ITS-S IPv6 node ’IPv6 node’ (’IPv6 host’ or I’Pv6router’) implementing functions of anITS station

[ISO-21210]

ITS-S IPv6 router ’IPv6 router’ implementing routing ca-pabilities of an ITS station.

[ISO-21210]

ITS-S IPv6 router serving anITS-S IPv6 LAN

’ITS-S IPv6 router’ that is connectingan ’ITS IPv6 LAN’ to other ’ITS IPv6LAN’s or the global Internet.

[ISO-21210]

flow sequence of packets corresponding tothe same flow profile between a sourceand its destination(s)

flow profile sequence of packets that have the sameapplication requirements

legacy IPv6 node ’IPv6 node’ that conforms to RFC 4294(IPv6 Node Requirements) and func-tions without additional IPv6 network-ing capabilities

[ISO-21210]

link-local IPv6 address ’IPv6 address’ corresponding to a ’link-local IPv6 unicast address’

[ISO-21210][rfc4291]

mobile edge multihoming Possibility for a mobile node (’IPv6host’ or ’IPv6 router’ serving a ’IPv6mobile network’) to connect simultane-ously to the Internet through multiplepoint of attachments, either using mul-tiple communication medium or usingmultiple interfaces of the same commu-nication medium, or through multiple’IPv6 mobile routers’ serving the same’IPv6 mobile network’.

[ISO-21210]

mobile ITS-S IPv6 LAN ’ITS-S IPv6 LAN’ having the capabiltyof changing its point of attachment tothe ITS domain or the Internet

[ISO-21210]

mobile ITS-S IPv6 LAN node ’IPv6 node’ on a ’ mobile ITS-S IPv6LAN’

[ISO-21210]

mobile ITS-S IPv6 LAN node ’IPv6 node’ on a ’ mobile ITS-S IPv6LAN’

[ISO-21210]

network mobility support A network function allowing an entiremobile ’IPv6 subnet’ or ’IPv6 mobilenetwork’ to change its point of attach-ment to the Internet, and, thus, itsreachability in the topology, without in-terrupting IP packet delivery to or fromthis ’IPv6 mobile network’

[ISO-21210][rfc3753] [rfc4885]




Term Definition Referencetunnel a forwarding path between two nodes

on which the payload consists of encap-sulated packets.

[ISO-21210]

Table B.1: Terminology for IPv6 Networking


APPENDIX C

List of acronyms

2G 2nd Generation mobile telecommunications3G 3rd Generation mobile telecommunicationsA-GPS Assisted GPSAnaVANET ANAlyzer for Vehicular Adhoc NETworks

AP Access PointAR access routerASN.1 Abstract Syntax Notation One

AU Application Unit

BA Binding Acknowledgement

BC Binding Cache

BE Binding Error

BID Binding Identification number

BOP Basic Open Platform

BU Binding Update

BUL Binding Update List

BR border routerBT Bluetechnix Mechatronische Systeme GmbH

C2C-CC Car-to-Car Communication ConsortiumC2CNet Car-to-Car NetworkCALM Communications Access for Land MobilesCAM Co-operative Awareness Messages

CCU Communication and Control UnitCDMA Code Division Multiple Access

CE Correspondent Entity

CEN European Committee for Standardization

CI Communication InterfaceC-ITS Cooperative Intelligent Transportation Systems

C-ITSS central ITS stationCIMAE Communication Interface Management Adaptation Entity

CN Correspondent Node

CoA Care-of AddressCoDrive Co-Pilote pour une Route Intelligente et des Véhicules Communicants

Coopers Co-operative Systems for Intelligent Road Safety

CoT Care-of TestCoTI Care-of Test InitCR central routerCVIS Cooperative Vehicle-Infrastructure Systems

DAD Duplicated Address Detection

DENM Decentralized Environmental Notification Messages

DHAAD Dynamic Home Agent Address Discovery

DHCP Dynamic Host Configuration Protocol

DMIPS Dhrystone MIPS, Million instructions per second

DNS Domain Name System

DoT U.S. Department of Transportation

DriveC2X Connecting vehicles for safe, comfortable and green driving on European roads

DSRC Dedicated Short Range Communications

127


EC European Commission

ETSI European Telecommunications Standards Institute

FlowID Flow IdentifierFM Frequency Modulation

FMIPv6 Fast Handovers for Mobile IPv6FOT Field Operational Test

FOTsis Field Operational Test on Safe, Intelligent and Sustainable Road Operation

FP6 Sixth Framework Programme

FP7 Seventh Framework Programme

GLONASS Global Navigation Satellite System

GeoNet IPv6 GeoNetworking

GPRS General Packet Radio ServiceGPS Global Positioning System

GPSR Greedy Perimeter Stateless Routing

GSM Global System for Mobile communications

HA home agent

HIP Host Identity Protocol

HMIPv6 Hierarchical Mobile IPv6HNA Host and Network AssociationHoA Home AddressHoT Home TestHoTI Home Test InitHSPA High Speed Packet Access

I2V Infrastructure-to-VehicleICMPv6 Internet Control Message Protocol version 6

ICT Information Communication Technologies

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IME Interface Management Entity

INP Internal Network PrefixINPA Internal Network Prefix AdvertisementInria Institut National de Recherche en Informatique et en Automatique

INPD IPv6 Internal Network Prefix Discovery

IINP ITS Station Internal Network PrefixIP Internet ProtocolIPFR IP Filter RuleIPsec Internet Protocol security

IPTE Schalk & Shalk OGIPv6 Internet Protocol version 6ISO International Organization for Standardization

ITS Intelligent Transportation Systems

ITSSP ITS Station ProtocolITSSPD ITS Station Protocol DaemonITS-S ITS stationITSSv6 web page http://www.itssv6.eu

IT Institut Mines TelecomITU International Telecommunication UnionL2 Layer 2

L2TP Layer-2 Tunneling Protocol

L3 Layer 3

LAN Local Area NetworkLDM Local Dynamic Map

LLC Logical Link Control

LTE Long Term Evolution

LS Location ServiceLT Location TableLW lesswireMAC Medium Access ControlMADM Multiple Attribute Decision Making

MAN Metropolitan Area Network

MANET Mobile Ad-hoc NetworkMAP Mobility Anchor Point

MCoA Multiple Care-of Addresses Registration

MIB Management Information Base

MIPS Million instructions per second

MLME Medium Access Control (MAC) Layer Management Entity

MN Mobile NodeMNN mobile network nodeMNP Mobile Network PrefixMNPP Mobile Network Prefix Provisioning



MobiSeND Mobile Secure Neighbor Discovery

MR mobile routerMTU Maximum Transmission UnitNA Neighbor Advertisement

NAT Network Address TranslationNDP Neighbor Discovery Protocol

NEMO Network Mobility

NemoBS Network Mobility Basic Support

NEPL NEMO Platform for LinuxNMEA National Marine Electronics AssociationNS Neighbor Solicitation

NTP Network Time ProtocolOASIS Operation of Safe, Intelligent and Sustainable Highways

OBU On-Board UnitOLSR Optimized Link State Routing

OSI Open Systems Interconnection

OSPF Open Shortest Path First

PAN Personal Area NetworkPathID Path IdentifierPDR Packet Delivery Ratio

PFBU Peer Flow Binding Update

PHY Physical

P-ITSS personal ITS station

PM Person-MonthPLME PHY Layer Management Entity

PMIPv6 Proxy Mobile IPv6

PPP Point-to-Point ProtocolPR personal router

PRESERVE Preparing Secure Vehicle-to-X Communication Systems

QoS Quality of Service

R2C Roadside ITS station to Central ITS stationRA Router AdvertisementRADVD Router Advertisement DaemonRDS Radio Data System

RFC Request for Comments

RIPng Routing Information Protocol

R-ITSS roadside ITS stationRO Route Optimization

RPDB Routing Policy Database

RS Router SolicitationRSSI Received Signal Strength Indication

RSU Road Side UnitRR roadside routerRTT Round-Trip Time

SafeSpot Cooperative vehicles and road infrastructure for road safety

SAP Service Access PointSAT ITS station access technologies layer

SAW Simple Additive Weighing

SCORE@F Système COopératif Routier Expérimental Français

SCTP Stream Control Transmission ProtocolSeVeCom Secure Vehicular CommunicationSF ITS station facilities layer

SHIM6 Level 3 Multihoming Shim Protocol for IPv6

SHIM6 Site Multihoming by IPv6 Intermediation

SLAAC Stateless Address Auto-Configuration

SME ITS station management entity

SMIv2 Structure of Management Information Version 2

SNMP Simple Network Management Protocol

SNT ITS station networking & transport layer

SPI Security Parameter Index

SSE ITS station security entity

STP Specific Target Platform

SZTAKI Magyar tudomanyos akademia szamitastechnikai es automatizalasi kutato intezet

SZT SZTAKITC204 WG16 Technical Committee 204 Working Group 16

TCP Transmission Control ProtocolUDP User Datagram Protocol

UMU Universidad de MurciaUMTS Universal Mobile Telecommunications System



UTC Coordinated Universal TimeV2C Vehicle ITS station to Central ITS stationV2I Vehicle-to-InfrastructureV2L Vehicle ITS station to legacy system

V2P Vehicle ITS station to Personal ITS stationV2R Vehicle ITS station to Roadside ITS stationV2V Vehicle ITS station to Vehicle ITS stationVANET Vehicular Ad-hoc NetworkV-ITSS vehicle ITS stationVR vehicle routerVCI Virtual Communication InterfaceWAVE Wireless Access in Vehicular EnvironmentsWG Working Group

WGS-84 World Geodetic System 84

WIMAX Worldwide Interoperability for Microwave Access

WLAN Wireless Local Area Network

WSMP Wireless Access in Vehicular Environments (WAVE) Short Message Protocol

XML Extensible Markup Language


Bibliography

[ETSI-EN-302-665] Intelligent Transport Systems (ITS); Communications Architecture, September 2010.ETSI EN 302 665 V1.1.1 (2010-09). pages 14, 19

[ETSI-EN-302-931] Intelligent Transport Systems (ITS); Vehicular Communications; Geographical Area Def-inition, December 2010. Draft ETSI EN 302 931 V1.0.0 (2010-12). pages 111

[ETSI-TR-101-555] Intelligent Transport Systems (ITS); Analysis of IPv6 for networking, 2012. ETSI TR101 555. pages 12

[ETSI-TR-102-863] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applica-tions; Local Dynamic Map (LDM); Rationale for and guidance on standardization, June 2011.ETSI TR 102 863 V1.1.1 (2011-06). pages 21, 45, 47

[ETSI-TS-102-636-4-1] Intelligent Transport Systems (ITS); Vehicular Communications; Part 4: Geograph-ical Addressing and Forwarding for Point-to-Point and Point-to-Multipoint Communications;Sub-part 1: Media-Independent Functionality, June 2011. ETSI TS 102 636-4-1 V1.1.1 (2011-06). pages 18, 82, 110

[ETSI-TS-102-636-4-2] Intelligent Transportation Systems (ITS); Vehicular Communications; Part 4: Ge-ographical Addressing and Forwarding for Point-to-Point and Point-to-Multipoint Communica-tions; Sub-part 2: Media-Dependent Functionalities for ITS-G5A media, May 2010. ETSI, workin progress, ETSI-TS-102-636-4-2. pages 18, 82

[ETSI-TS-102-636-6-1] Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking;Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworkingProtocols, March 2011. ETSI TS 102 636-6-1 V1.1.1 (2011-03). pages 18, 82

[ETSI-TS-102-637-2] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applica-tions; Part 2: Specification of Cooperative Awareness Basic Service, March 2011. ETSI TS 102637-2 V1.2.1 (2011-03). pages 21, 43, 47

[ETSI-TS-102-637-3] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applica-tions; Part 3: Specifications of Decentralized Environmental Notification (DENM) Basic Service,September 2010. ETSI TS 102 637-3 V1.1.1 (2010-09). pages 21, 43, 47

[ETSI-TS-102-723-1] ETSI. Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 1: Architectureand addressing schemes, October 2011. pages 19

[ETSI-TS-102-723-3] ETSI. Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 3: Interfacebetween management entity and access layer, October 2012. pages 19

[ETSI-TS-102-723-4] ETSI. Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 4: Interfacebetween management entity and network and transport layers, October 2011. pages 19

131


[ETSI-TS-102-731] ETSI. Intelligent Transport Systems (ITS); Security; Security Services and Architecture,October 2010. pages 20

[GeoNet-D1.2] GeoNet. D1.2 Final GeoNet Architecture Design. Public deliverable, June 2010. pages 27, 82

[GeoNet-D2.2] GeoNet. D2.2 Final GeoNet Specification. Public deliverable, June 2010. pages 77, 101

[ISO-16788] ISO. Intelligent transport systems – Communications access for land mobiles (CALM) – IPv6Networking Security, April 2012. ISO/NP 16788:2012(E). pages 12

[ISO-16789] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – IPv6Networking Optimization, April 2012. ISO/NP 16789:2012(E). pages 12

[ISO-21210] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – IPv6Networking, January 2011. ISO 21210:2011(E). pages 9, 12, 18, 25, 27, 29, 76, 123, 124, 125, 126

[ISO-21212] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – CALMusing 2G Cellular Systems, April 2008. ISO/IS 21212:2008. pages 20

[ISO-21213] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – CALMusing 3G Cellular Systems, April 2008. ISO/IS 21212:2008. pages 20

[ISO-21214] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – CALMInfra Red, April 2008. ISO/IS 21214:2008. pages 20

[ISO-21215] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – CALMM5 , April 2010. ISO/IS 21215:2010. pages 20

[ISO-21217] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – Ar-chitecture, April 2010. ISO 21217:2010(E). pages 12, 14

[ISO-21218] ISO. Intelligent transport systems – Communications access for land mobiles (CALM) – Mediumservice access points, August 2008. ISO/DIS 21218:2008(E). pages 60

[ISO-24102] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – Man-agement, September 2010. ISO/FDIS 24102:2010(E). pages 12, 19, 28, 45, 47

[ISO-24102-1] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – Part1: ITS station management, May 2011. ISO/CD 24102-1:2011(E). pages 19, 23, 46, 47, 49, 52

[ISO-24102-2] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – Part2: Management service access points, May 2011. ISO/CD 24102-2:2011(E). pages 49, 60, 61,107, 108, 109

[ISO-24102-4] ISO. Intelligent transport systems – Communications Access for Land Mobiles (CALM) – Part4: Fast service advertisement protocol (FSAP), May 2011. ISO/CD 24102-4:2011(E). pages 43

[ISO-29281-2] ISO. Intelligent transport systems – Communication Access for Land Mobiles (CALM) – Part2: Fast networking & transport layer protocol (FNTP), June 2011. ISO/CD 29281-2:2011(E).pages 18

[ITU-T-X.680-ASN1:2002] Information technology – Abstract Syntax Notation One (ASN.1): Specificationof basic notation, July 2002. ITU-T Rec. X.680 ISO/IEC 8824-1. pages 109

[Lee2011b] Jong-Hyouk Lee, Thierry Ernst, and Jean-Marie Bonnin. Cross-layered architecture for securingIPv6 ITS communication: Example of pseudonym change. In Cross Layer Design (IWCLD),2011 Third International Workshop on, pages 1–6, 2011. pages 20, 30, 84

[Lee2012a] Jong-Hyouk Lee, Jiefeng (Terence) Chen, and Thierry Ernst. Securing mobile network prefixprovisioning for NEMO based vehicular networks. Mathematical and Computer Modelling, 55(1-2):170–187, January 2012. pages 20, 30, 84, 90, 92

[X.800] X.800 - Data Communication Networks: Open Systems Interconnection (OSI) - Security, Struc-ture and Applications - X.800 : Security architecture for Open Systems Interconnection forCCITT applications, 1991. ITU Recommendations X.800. pages 84, 85, 86, 87



[rfc2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460 (DraftStandard), December 1998. Updated by RFCs 5095, 5722, 5871. pages 124

[rfc2578] K. McCloghrie, D. Perkins, and J. Schoenwaelder. Structure of Management Information Version2 (SMIv2). RFC 2578 (Standard), April 1999. pages 107, 108, 109

[rfc2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, and D. Spence. Generic AAA Architecture.IETF RFC 2903, Aug. 2000. pages 121

[rfc3411] D. Harrington, R. Presuhn, and B. Wijnen. An Architecture for Describing Simple NetworkManagement Protocol (SNMP) Management Frameworks. RFC 3411 (Standard), December2002. Updated by RFCs 5343, 5590. pages 109

[rfc3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz. Extensible AuthenticationProtocol (EAP). RFC3748, June 2004. pages 99, 121

[rfc3753] J Manner and M. Kojo. Mobility Related Terminology. RFC 3753 (Informational), June 2004.pages 123, 124, 125

[rfc3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775 (Proposed Standard),June 2004. Obsoleted by RFC 6275. pages 73

[rfc3776] Jari Arkko, Vijay Devarapalli, and Francis Dupont. Using ipsec to protect mobile ipv6 signalingbetween mobile nodesand home agents. RFC, June 2004. pages 87, 98

[rfc3810] R. Vida and L. Costa. Multicast Listener Discovery Version 2 (MLDv2) for IPv6. RFC 3810(Standards Track), June 2006. pages 101

[rfc3963] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility (NEMO) BasicSupport Protocol. RFC 3963 (Proposed Standard), January 2005. pages 26, 27, 72, 73, 76

[rfc3971] J. Arkko, J. Kempf, B. Zill, and P. Nikander. Secure neighbor discovery (send). RFC 3971(Proposed Standard), March 2005. pages 87, 98

[rfc3972] T. Aura. Cryptographically generated addresses (cga). RFC 3972 (Proposed Standard), March2005. Updated by RFCs 4581, 4982. pages 90

[rfc4022] R. Raghunarayan. Management Information Base for the Transmission Control Protocol (TCP).RFC 4022 (Proposed Standard), March 2005. pages 106, 109

[rfc4087] D. Thaler. IP Tunnel MIB. RFC 4087 (Proposed Standard), June 2005. pages 106, 109

[rfc4113] B. Fenner and J. Flick. Management Information Base for the User Datagram Protocol (UDP).RFC 4113 (Proposed Standard), June 2005. pages 106, 109

[rfc4285] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury. Authentication Protocol for MobileIPv6, January 2006. pages 87, 90

[rfc4291] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 4291 (Draft Standard),February 2006. Updated by RFCs 5952, 6052. pages 123, 125

[rfc4293] S. Routhier. Management Information Base for the Internet Protocol (IP). RFC 4293 (ProposedStandard), April 2006. pages 106, 109

[rfc4295] G. Keeni, K. Koide, K. Nagami, and S. Gundavelli. Mobile IPv6 Management Information Base.RFC 4295 (Proposed Standard), April 2006. pages 106, 109

[rfc4301] S. Kent and K. Seo. Security architecture for the internet protocol. RFC, 2005. pages 87, 98

[rfc4306] C. Kauffman. Internet Key Exchange (IKEv2) Protocol. IETF RFC 4306, Dec. 2005. pages 98,121

[rfc4443] A. Conta, S. Deering, and M. Gupta. Internet Control Message Protocol (ICMPv6) for theInternet Protocol Version 6 (IPv6) Specification. RFC 4443 (Draft Standard), 2006. pages 25



[rfc4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Discovery for IP version 6(IPv6). RFC 4861 (Draft Standard), September 2007. pages 25, 87

[rfc4862] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconfiguration. RFC 4862(Draft Standard), September 2007. pages 25, 82

[rfc4885] T. Ernst and H-Y. Lach. Network Mobility Support Terminology. RFC 4885 (Informational),July 2007. pages 73, 125

[rfc4886] T. Ernst. Network Mobility Support Goals and Requirements. RFC 4886 (Informational), July2007. pages 73

[rfc4888] C. Ng, P. Thubert, M. Watari, and F. Zhao. Network Mobility Route Optimization ProblemStatement. RFC 4888 (Informational), July 2007. pages 77

[rfc4889] C. Ng, F. Zhao, M. Watari, and P. Thubert. Network Mobility Route Optimization SolutionSpace Analysis. RFC 4889 (Informational), July 2007. pages 77

[rfc4941] T. Narten, R. Draves, and S. Krishnan. Privacy extensions for stateless address autoconfigurationin ipv6. RFC, 2007. pages 87

[rfc5191] D. Forsberg, Y. Ohba (Ed.), B. Patil, H. Tschofenig, and A. Yegin. Protocol for Carrying Au-thentication for Network Access (PANA). IETF RFC 5191, May 2008. pages 121

[rfc5488] S. Gundavelli, G. Keeni, K. Koide, and K. Nagami. Network Mobility (NEMO) ManagementInformation Base. RFC 5488 (Proposed Standard), April 2009. pages 106, 109

[rfc5555] H. Soliman. Mobile IPv6 Support for Dual Stack Hosts and Routers. RFC 5555 (ProposedStandard), June 2009. pages 32, 103

[rfc5571] B. Storer, C. Pignataro, Dos M. Santos, Bruno Stevant, and Laurent Toutain. Softwire Hub andSpoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2). RFC5571 (Standards Track), June 2009. pages 103

[rfc5648] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami. Multiple Care-of AddressesRegistration. RFC 5648 (Proposed Standard), October 2009. pages 26, 27, 72, 73

[rfc6088] G. Tsirtsis, G. Giarreta, H. Soliman, and N. Montavont. Traffic Selectors for Flow Bindings. RFC6088 (Proposed Standard), January 2011. pages 74

[rfc6089] G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, and K. Kuladinithi. Flow Bindings in MobileIPv6 and Network Mobility (NEMO) Basic Support. RFC 6089 (Proposed Standard), January2011. pages 74

[rfc6146] M. Bagnulo, P. Matthews, and van I. Beijnum. Stateful NAT64: Network Address and ProtocolTranslation from IPv6 Clients to IPv4 Servers. RFC 6146 (Standards Track), April 2011. pages103


itssv6deliverable itssv6strepgrantagreement210519 d2.2 ... · standards from the international...

Documents