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

Transcription

1 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs ICT : ICT for Mobility, Environmental Sustainability and Energy Efficiency ITSSv6 Deliverable ITSSv6 STREP Grant Agreement D2.2: Preliminary System Specification DATE 22nd May 2012 CONTRACTUAL DATE OF DELIVERY TO THE EC M12 ( ) ACTUAL DATE OF DELIVERY TO THE EC M14 ( ) EDITOR, COMPANY Thierry Ernst, Inria DOCUMENT CODE ITSSv6-D.2.2-PreliminarySystemSpecification-v1.1 SECURITY Public Project Coordinated by Thierry Ernst - Mines ParisTech / Inria thierry.ernst@mines-paristech.fr

2 Document History Release Date Reason of change Status Distribution /03/12 Final consolidated version Final Internal /05/12 Alignment with other deliverables Final EC 1

3 Contents Executive summary 9 Contributors 10 1 Introduction The ITSSv6 project Purpose of this deliverable Objectives and contributions Structure of the document ITS station reference architecture ITS station reference architecture overview OSI-like layered architecture Types of ITS stations ITS stations hosts and routers ITS stations and IPv ITS station networking and transport ITS station management ITS station security ITS station access technologies ITS station facilities ITS station applications ITS station service access points (SAP) ITS station IPv6 networking design IPv6 networking in the ITS station architecture: ISO IPv6 networking issues in the ITS station standards IPv6 networking issues ITS station architecture issues IPv6 protocol block design ITS station management entity design Open Issues

4 4 Path and flow management Terminology Overview Path management Flow management Flow requirements Flow registration Flow statistics Path selection Flows mapped to paths Flow policies Local ITS station information table Neighbor ITS station information table Path information table Flow requirement table Flow information table Flow statistics table Flow policy table Module IPv6 adaptation agent Overview Parameters maintained at the network layer Parameters maintained at the IPv6 layer Locator and identifier Service Parameters maintained at the GeoNetworking layer Mapping between management and IP parameters MN-REQUEST function parameters and corresponding events MN-COMMAND function parameters and corresponding actions IPv6 path management Procedure IPv6 flow management Architecture Feedback and update Module IPv6 traffic classifier Overview Relation between IPv6 networking modules IPv6 packets classification Feedback Policy Exchange Module IPv6 forwarding Overview Flow policies Management Algorithm Required actions

5 8 Module IPv6 mobility support IPv6 network mobility basic support (NEMO) IPv6 mobile edge multihoming (MCoA) Required actions Module IPv6 ad-hoc networking IPv6 Internal Network Prefix Discovery (INPD) INPD: Motivations INPD: Description INPD: Interaction with other modules INPD: Message flows INPD: Proactive mode message flows INPD: Reactive mode message flows Module IPv6 over GeoNetworking IPv6 over GeoNetworking: description GeoNetworking Layer Required actions Module IPv6 security Overview ITU s definition of security services and mechanisms Security services Security mechanisms Security services offered by the IPv6 security module IPv6 security protocols implementing security services Interaction with other modules and entities Interaction with ITS station management entity Interaction with ITS station security entity Interaction with other IPv6 modules Pseudonym configuration at the IPv6 layer Pseudonym Pseudonym configuration Pseudonym update due to mobility Pseudonym change due to the mobility lifetime expiration Pseudonym change due to the pseudonym lifetime expiration Example of pseudonym change at the IPv6 layer Access Control Mechanisms for IPv6 communications General overview of access control Access control mechanisms provided by the IPv6 security module Example of network access control with EAP authentication support Module IPv6 multicasting Overview Required actions Module IPv4-IPv6 interoperability Overview Required actions

6 14 MN-SAP: Interface between Management and Network entities Overview N-Parameter exchange MN-SET command MN-SET.request MN-SET.confirm MN-GET command MN-GET.request MN-GET.confirm N-Parameter for IPv N-Parameters for GeoNetworking Parameters and primitives for path and flow management MN-REQUEST and MN-COMMAND MN-REQUEST STAGeoNot MN-REQUEST STATopoNot MN-REQUEST STAServNot MN-REQUEST PathNot MN-REQUEST PathMetricNot MN-REQUEST FlowStatistics MN-COMMAND PathMNGT MN-COMMAND FlowClassificationRule MN-COMMAND FlowPolicy MN-COMMAND FlowFeedback MN-COMMAND STAServDiscov SN-SAP: Interface between Networking & Transport Layer and Security Entity Overview Service Interfaces of the SN-SAP SN-SAP Parameters A Candidate technologies for access control in ITS 121 B Terminology 123 C List of acronyms 127 Bibliography 131

7 List of Figures 2.1 Simplified ITS Station (ITS-S) Reference Architecture Detailed ITS Station (ITS-S) Reference Architecture Types of ITS stations ITS station communication management ITS Station Service Access Points (SAP) MN-Command and MN-Request service primitive MN-COMMAND Description MN-REQUEST Description IPv6 functional modules in ISO Definition of path in the ITS station architecture Overview of the relation between ITS station management entity (SME) and other entities Relation between management parameters and identifiers Cross-layer information flow for path and flow management Controllable communication points Possible paths between two vehicle ITS stations Network around vehicle ITS station IPv6 Adaptation Agent Procedure of Path Management Routing architecture of the IPv6 networking stack Procedure of feedback and flow management IPv6 session continuity with NEMO Basic Support IPv6 mobile edge multihoming Message Flow Example in INPD Proactive Mode 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 network prefixes Message Flow Example in the INPD Reactive Mode: A node sends its INPS message to a specific node to quickly obtain the specific node s internal network prefix

8 11.1 Security services achieved by security mechanisms at the IPv6 layer Mapping of security services to types of IPv6 node Mapping of security mechanisms to types of Pv6 node Security mechanisms provided by IPv6 security protocols Mapping of security protocols to types of IPv6 node Mapping of security protocols according to the type of interface (internal and external) Considered network topology Pseudonym change Vehicle ITS accessing to Internet through a roadside ITS station Interface Between the Management Entity and the Network Layer N-Parameters for GeoNetworking Cross-layer information flow for path and flow management Relation with the ITS station security entity through SN-SAP A.1 EAP Authentication Framework

9 List of Tables 4.1 Local ITS station information table Neighbor ITS station information table Path information table CI parameters specified in [? ] Flow requirement table Flow information table Flow statistics table Flow policy table Mapping between Events in IPv6 Network Protocol Block and MN-REQUEST Mapping between Actions in IPv6 Network Protocol Block and MN-COMMAND MN-SET.request parameters MN-SET.confirm parameters MN-GET.request parameters MN-GET.confirm parameter description New MN-REQUESTs New MN-COMMANDs Parameters of MN-REQUEST STAGeoNot Parameters of MN-REQUEST STATopoNot Parameters of MN-REQUEST STAServNot Parameters of MN-REQUEST PathNot Parameters of MN-REQUEST PathMetricNot Parameters of MN-REQUEST FlowStatistics Parameters of MN-COMMAND PathMNGT Parameters of MN-COMMAND FlowClassificationRule Parameters of MN-COMMAND FlowPolicy Parameters of MN-COMMAND FlowFeedback Parameters of MN-COMMAND STAServDiscov Description of SN-Request.No B.1 Terminology for IPv6 Networking

10 Executive summary This document is a public deliverable (D2.2) of ITSSv6 (IPv6 Station Stack for Cooperative ITS Field Operational Tests), a FP7 European Project, which aims at specifying and developing an enhanced IPv6 protocol stack optimized for Intelligent Transportation Systems (ITS) use cases complying with Cooperative ITS (C-ITS) standards. It presents a preliminary specification of the IPv6 protocol block of the ITS station networking & transport layer of the ITS station reference architecture jointly defined by the International Organization for Standardization (ISO) (Technical Committee 204) and the European Telecommunications Standards Institute (ETSI) (Technical Committee ITS) for C-ITS communications. The IPv6 protocol block is a collection of features corresponding mostly to protocols specified by the Internet Engineering Task Force (IETF). These features are selected specifically to meet ITS use cases 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 is the minimum set of modules to be implemented for each type of IPv6 node composing ITS stations (vehicle ITS stations, roadside ITS stations, central ITS stations and personal ITS stations). Types of IPv6 nodes include IPv6 routers, presently access router (AR), mobile router (MR), border router (BR), home agent (HA) and IPv6 hosts. Modules defined in the ISO standard CALM: IPv6 Networking [ISO-21210] are taken as an input and extended with new features required to secure and to optimize IPv6 communications and to fulfill other needs expressed by C-ITS Field Operational Tests (FOTs). The preliminary pecification reported in this document are being contributed to both ISO, CEN and ETSI. The present specification of the IPv6 protocol block will be revised, taking into account standardization progress and reported in a new document entitled ITSSv6 D2.4: Final System Specification to be published in February The revision will specify the modules which are not yet totally detailed and will include IPv6 features required for personal ITS stations which are not yet treated. 9

11 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

12 CHAPTER 1 Introduction 1.1 The ITSSv6 project ITSSv6 (IPv6 Station Stack for Cooperative ITS Field Operational Tests (FOTs) is an European Project (STREP) from the 7th Programme Framework (Grant Agreement ), Call 6 (ICT : ICT for Mobility, Environmental Sustainability and Energy Efficiency) started in February 2011 and lasting until January The project is coordinated by Institut National de Recherche en Informatique et en Automatique (Inria) and gathers Universidad de Murcia (UMU),Institut Mines Telecom (IT), lesswire (LW), Magyar tudomanyos akademia szamitastechnikai 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 of ETSI / ISO ITS station reference architecture. ITSSv6 builds on existing standards from ETSI, ISO and IETF and IPv6 software available from the CVIS and GeoNet projects. The IPv6 lts station stack provided by ITSSv6 supports at least p and 2G/3G media types and 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 features; 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, presentations made at conferences or workshops, information about events) are made available on the project s web site ( as it becomes available. 11

13 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 stack specification: T2.1: System Requirement Analysis Application requirements in terms of IPv6 networking are analyzed considering output from FP6 projects (CVIS, SafeSpot, Coopers and SeVeCom) and objectives of known FOTs. Functionalities to be provided in the ITS Station architecture (ISO and ETSI) are analyzed at all layers of the architecture and the IPv6 networking layer features of the ITS Station are classified into three classes according to the expected complexity, known availability of a protocollevel specification and implementation, and urgency (MS21). Needs and capabilities in terms of hardware (CPU, memory,...), network architecture (public or private access network, in-vehicle network or single in-vehicle node,...), wireless technologies (802.11p, WiMaX, Satellite, 2G/3G,...) and Internet connectivity (availability of IPv6,...) of third parties identified in T6.1 are considered. This work is reported in D2.2 and revised in D2.4. T2.2: IPv6 protocol stack specification IPv6 networking features identified and classified in T2.1 are fully specified. Specifications are written at the ITS station architecture level if protocol-level specifications already exists (Class-1 items) in order to ease their integration into ITS Station specification (ISO and ETSI). For features requiring extensions (Class-2 items), these extensions are specified in the context of the ITS Station architecture. For features missing a specification (Class-3 items), a protocol-level specification is written and proposed in scientific papers, possibly to the relevant SDO (likely IETF). Specifications are formatted into IETF internet-drafts style and passed to WP3 (MS22 and MS23) for implementation and WP6 (MS22, MS23 and MS24) for potential standardization in the relevant SDO. This work is reported in D2.2 and revised in D Objectives and contributions After careful analysis of the FOT needs and existing ITS standards related to IPv6, we propose, from a specification point of view, a new design of the IPv6 protocol block of the ITS station networking & transport layer. The new IPv6 protocol block, as compared to the current IPv6 networking standard [ISO-21210], is interacting with the ITS station management entity and the ITS station security entity through respectively the MN-SAP and SN-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 security while existing modules are brushed up and extended. These are specified, and specifications have been provided to ISO for insertion in standards (IPv6 networking security [ISO-16788], IPv6 networking optimization [ISO-16789], ITS station architecture [ISO-24102], ITS station management [ISO-21217] and IAnalysis of Pv6 for networking [ETSI-TR ]). The major contributions of the ITSSv6 project for the specification of IPv6 networking are, in the 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

14 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 flow management; 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 between the IPv6 protocol block and the ITS station management entity (MN-SAP); The specification of the functions and parameters required for the interaction between the 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 ISO and ETSI standards; Chapter 3 analyzes the current IPv6-related standards on IPv6 networking, discusses their 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 given path; 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 management entity and IPv6 networking protocol block (MN-SAP); Chapter 15 details the Service Access Point (SAP) between the ITS station security entity 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. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 13/134

15 CHAPTER 2 ITS station reference architecture In this chapter, we describe the ITS station reference architecture as currently defined in standards from the International Organization for Standardization (ISO) (Technical Committee 204) and the European Telecommunications Standards Institute (ETSI) (Technical Committee ITS). 2.1 ITS station reference architecture overview In an effort towards harmonization, the European ITS community (EC s funding programs FP6 and FP7, the Car-to-Car Communication Consortium) and international standardization bodies (ISO TC204 WG16 and ETSI TC ITS) have invested significant effort into the specification of a communication architecture suitable for a variety of C-ITS needs. This harmonization effort, initially conducted by COMeSafety in 2010 (European FP6 Specific Support Action), considered early work performed by ISO TC204 WG16 and other stakeholders 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 TC ITS [ETSI-EN ] and ISO TC 204 [ISO-21217]. This architecture is illustrated on Figure 2.1. Both ISO and ETSI architecture standards are based on the same terminology and tend to converge although there are still remaining differences between the two. This lack of consistency shall disappear as standards are revised (revision is undergoing as of February 2012). The design principle of this communication architecture is to support simultaneously a diversity 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 p vehicular WiFi, 2.5 GHz IEEE n urban WiFi), satellite, infrared, 60 GHz millimeter-wave and possibly others, for a variety of communication scenarios (vehicle-based, roadside-based and Internet-based). These access technologies provide wired and wireless broadcast, unicast and multicast communications between mobile stations, between mobile and fixed stations and between fixed stations. A fundamental advantage of this design concept over currently deployed systems is that applications are abstracted from the access technologies and the networks that transport the 14

16 information from the source to the destination(s). This means that ITS stations applications are not limited to the availability and characteristics of a single access technology and networking protocol stack. Communication management functions make optimal use of all these resources transparently to the applications. ISO TC204 WG16, also known as CALM (Communications Access for Land Mobiles) and established at ISO in 200, is the birth place of many of the concepts behind the communication architecture before it was harmonized by COMeSafety OSI-like layered architecture As shown on Figure 2.1, the ITS station reference architecture is layered. At the top sits the application layer, immediately below the facilities layer (middleware providing a set of standard services to the applications), below it the networking and transport layer and at the bottom the access technologies layer (providing the physical communication media). This ITS station reference architecture differs from conventional OSI layered architectures by the addition of vertical entities providing cross-layer management (ITS station management) and security functions (ITS station security) and the new middle layer (ITS facilities) providing common services to the applications (maps, positioning, time stamping, etc). The network layer itself also comprises a variety of networking protocols, including IPv6 (for Internet-based communications), GeoNetworking of FAST (for roadside-based and vehiclebased communications), a combination of both (IPv6 GeoNetworking) and possibly other protocols. The particular novelty from a design view point, compared to a typical OSI 7-layer architecture, are the two vertical entities, i.e. the ITS station management entity and the ITS station security entity performing a number of cross-layer functions. Cross-layer functions are not new in the literature (ITS no less than other use cases), but it is the first time this is explicitly shown on architecture diagrams. The main difference between ETSI and ISO documents lies in the specification of the ITS station management entity. So far, ISO CALM has concentrated its effort on the cross-layer functions to ensure a given communication flow is matched to a particular communication interface (CI) according to application needs and current network conditions. ETSI is not too much concerned about this issue because the current ETSI work is largely focused on the used of the p access technology whereas the focus of the ISO work (CALM) has always been the simultaneous support of a variety of access technologies Types of ITS stations Historically, the terms On-Board Unit (OBU), Road Side Unit (RSU) and Application Unit (AU) are used in the automotive industry. However, these terms were not defined with a networking view in mind and have therefore become obsolete in Cooperative ITS. In addition, the ITS station reference architecture doesn t use these terms either because they were confusing the discussion. This led to the definition of the ITS station (ITS-S) and a distinction of the supported functions according to the type of environment or network where it is be located. As such, four types of ITS stations are currently defined, as described on Figure 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 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 15/134

17 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,...) ITS stations hosts and routers The ITS station is defined as a bounded secured managed domain. In the most general case the functions of an ITS station (ITS-S) are split into a router (ITS-S router) and hosts (ITS-S host) attached to the ITS-S router via some ITS station internal network. The router and hosts functions may also be merged into a single entity ITS stations and IPv6 In most cases, an ITS station will be linked to other ITS stations and networked entities via IPv6, either a legacy IPv6 network or a proprietary IPv6 network. In some very specific cases like for instance direct communication between neighbor vehicle ITS stations using p, IPv6 may be replaced by some ITS-specific networking protocol like GeoNetworking or a legacy 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-S IPv6 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 also known as mobile routers (MRs) and mobile network nodes (MNNs) when continuous Internet connectivity is supported. In the roadside ITS station, the nodes executing the ITS-S router functions are the ITS-S IPv6 roadside routers (RRs) and the ITS-S IPv6 border routers (BRs). Roadside ITS-S IPv6 routers are also known as the ITS-S IPv6 access router (AR) when they provide access to ITS-S IPv6 mobile router (MR). border routers (BRs) are the ITS-S ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 16/134

18 Figure 2.2: Detailed ITS Station (ITS-S) Reference Architecture IPv6 routers connecting the ITS station to the Internet or other ITS stations. The ITS-S host functions may be implemented by an ITS-S IPv6 router, or by ITS-S IPv6 hosts. 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 ITS stations and the ITS-S home agents (HAs) for supporting IPv6 mobility. The ITS-S host 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 Application Unit (AU) are meant for IPv6 mobile router (MR), IPv6 access router (AR) and IPv6 node, respectively. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 17/134

19 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) can support a variety of networking protocols. Currently, IPv6 Networking and the newly developed FNTP protocol (Fast Networking & Transport layer Protocol, previously known as FAST) are specified at the ISO TC204 level, respectively in ISO [ISO-21210] and [ISO ], whereas GeoNetworking (media-dependent [ETSI-TS ] and media-independent [ETSI-TS ]) and IPv6 over GeoNetworking adaptation layer [ETSI-TS ] are specified by ETSI. More networking protocols could be added if needed. The terms Mobility Extensions indicated in the IPv6 + Mobility Extensions box of the SNT is misleading as these are extensions of IPv6 only needed for mobile ITS stations such as vehicle or personal ITS stations. This is a detail that should not appear on this figure describing 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 functions including path selection based on pre-set policies, regulations, static and dynamic capabilities of the different access technologies. The SME is responsible for the selection of the best communication path (communication interface and end-node) according to the flow requirements expressed by the ITS station applications, the access technologies characteristics and the current network conditions. The ITS station management entity must thus interact with the ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 18/134

20 horizontal layers in order to make this determination and more particularly with the ITS station networking & transport layer (SNT) that must update its forwarding tables according to rules provided by the SME. This is illustrated on Figure 2.4 [ETSI-EN , ISO ]. Figure 2.4: ITS station communication management To exploit the availability of multiple access technologies, the SME supports different types of handover, including: those involving a change of the point of attachment to the network without a change of access technology; those involving a change of the point of attachment to the network with a change of access technology; those involving reconfiguration or change of the network employed to provide connectivity; and those involving both a change of the point of attachment to the network and network reconfiguration. The SME functions are under specification by ISO TC204 WG16 [ISO-24102]. New ISO work items have been launched and published ISO standards are under revision. In addition, ETSI TC ITS has also opened work items related to cross-layer functions and the ITS station management, in order to comply with the ITS standardization mandate M/453 from the European Commission. Existing ETSI work items include Cross-layer architecture [ETSI-TS ], MI interface [ETSI-TS ], MN interface [ETSI-TS ]. These work items should actually simply refer to the existing ISO TC204 standards, otherwise ISO and ETSI standards would diverge. The interactions between the ITS station management entity and the horizontal layers is performed via Service Access Points (SAPs) (see Section 2.8). ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 19/134

21 2.4 ITS station security D2.2: Preliminary System Specification The vertical ITS station security entity provides common security functionalities to all the horizontal layers and maintains security credentials used by these [ETSI-TS ]. The ITS station security entity does not perform any particular security mechanism or protocol. Protocol dedicated security mechanisms and security protocols are implemented at each layer. For instance, IPv6 dedicated security mechanisms and protocols, which are subject to modifications or replacement, shall be implemented at the IPv6 protocol block, not at the ITS station security entity [Lee2011b, Lee2012a]. This provides more modularity and minimizes 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 are stored and maintained at the security entity with other security related parameters and status information. Upon request from horizontal layers, atomic security operations are provided by 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 is performed 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 technologies can be used simultaneously, and vary according to the type of ITS station and its purpose. In order to support any given access technology, a new standard must specifying the parameters and functions so that the access technology could be recognized by the ITS station. Currently, the support of several wireless access technologies (infrared [ISO-21214], microwave [ISO-21215], millimeter wave, 2G/3G [ISO-21212, ISO-21213]) and wired access technologies (Ethernet) is already specified, in either ISO or ETSI standards. More access technologies could be supported in the future, without any impact on the other layers of the ITS station reference architecture. It is of course not required for a given deployment to implement neither all these access technologies nor to implement the specific functions required to support all these access technologies. So, the purpose of the standard is to specify how a given access technology, if needed, can be integrated into the ITS station. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 20/134

22 2.6 ITS station facilities D2.2: Preliminary System Specification 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 by other ITS stations (vehicles, roadside) and freeing them from the necessary message signaling 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 otherwise have broadcast potentially similar information, therefore increasing consumption of network resources and processing power. The current facilities include CAM (Co-operative Awareness Messages) [ETSI-TS ] 1-hop broadcast messages transmitted in the immediate vicinity mainly for time-critical road safety purposes, and Decentralized Environmental Notification Messages (DENM) (Decentralized Environmental Notification Messages) [ETSI-TS ] 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 ] together with other information. 2.7 ITS station applications As shown on Figure 2.2, applications supported by the ITS station reference architecture are generally spread in three categories: Road safety: this category comprises all applications that are designed to render road traffic safer. These include both applications such as emergency braking or lane departure notification which require short range time-critical for immediate actions from the vehicles, and longer-range applications such as road hazard events (black ice, vehicle in 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 improve road traffic. These include road itinerary planning, green wave, road diversion, and require constant exchange of informations between vehicles, the roadside infrastructure and some traffic information servers. Other applications: These are not necessarily ITS-specific applications, but must be supported in other to provide a better transportation experience to the road users. They thus include comfort and infotainment applications. This category is also often referred to as value added applications. These applications rely partly on services offered by the ITS station facilities layer. As a result of the messages processed by the ITS station facilities, applications may for example display messages on the navigation system in the vehicle. These applications may also issue messages to other ITS stations without subsequently involving the ITS station facilities. For example, as a result of receiving a service notification by the ITS station facilities, of a charging spot for electric vehicle charging spot, the application may directly contact a server to enquire about the availability of the charging spot and book it. In addition, some ITS station applications may be completely standalone, i.e. not taking benefit of the ITS station facilities at all. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 21/134

23 All applications have specific communication requirements 1. These application requirements must be provided to the ITS station management entity in order to determine the capability of the ITS station to transmit the information and to determine the communication path (e.g. the access technologies) that should be used to route the packets given the requirements provided by the application. 2.8 ITS station service access points (SAP) The functional blocks of the ITS station communication architecture are interconnected via Service Access Points (SAPs) as presented in Figure 2.2. Management Security Between layers SAP M I M N M F M A SI SN SF SA IN N F F A Description SAP allowing the interaction between the ITS station management entity (SME) and the ITS station access technologies layer (SAT) SAP allowing the interaction between the ITS station management entity (SME) and the ITS station networking & transport layer (SNT) SAP allowing the interaction between the ITS station management entity (SME) and the ITS station facilities layer (SF) SAP allowing the interaction between the ITS station management entity (SME) and the ITS station applications SAP allowing the interaction between the ITS station security entity (SSE) and the IITS station access technologies layer (SAT) SAP allowing the interaction between the ITS station security entity (SSE) and the ITS station networking & transport layer (SNT) SAP allowing the interaction between the ITS station security entity (SSE) and the ITS station facilities layer (SF) SAP allowing the interaction between the ITS station security entity (SSE) and the ITS station applications SAP allowing the interaction between the ITS station access technologies and the ITS station networking & transport layer (SNT) SAP allowing the interaction between the ITS station networking & transport layer (SNT) and the ITS station facilities layer (SF) SAP allowing the interaction between the ITS station facilities layer (SF) and the ITS station applications Figure 2.5: ITS Station Service Access Points (SAP) 1 To 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 videoconferencing application ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 22/134

24 According to the ISO specifications [ISO ], the following types of services, illustrated 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 station 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 of a 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 station networking & transport layer (SNT) to trigger an action at the ITS station management entity (SME). MN-REQUEST.confirm: this management service primitive reports the result of a previous MN-REQUEST.request. Figure 2.6: MN-Command and MN-Request service primitive ISO [ISO ] indicates that both MN-COMMAND and MN-REQUEST supports up to 256 possible SAP functions. For MN-COMMAND five functions are currenrly defined; for MN-REQUEST, seven functions are currently defined. This is described in Table 2.8: MN-COMMAND Number Description 0 Reserved for future use. 1 to 5 Used 6 to 224 Reserved for future use. 225 For private non-standardized use Figure 2.7: MN-COMMAND Description ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 23/134

25 MN-REQUEST Number Description 0 Reserved for future use. 1 to 7 Used 8 to 224 Reserved for future use. 225 For private non-standardized use Figure 2.8: MN-REQUEST Description ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 24/134

26 CHAPTER 3 ITS station IPv6 networking design In this chapter, we analyze the IPv6 protocol block of the ITS station networking & transport layer as it is presently specified by International Organization for Standardization (ISO) in ISO [ISO-21210]. Section 3.1 presents the current content of ISO 21210, whereas Section discusses what IPv6 features are missing in ISO Following the design goals set up in ITSSv6 Deliverable D2.1 Preliminary System Recommendations, we propose to organize the IPv6 protocol block and the necessary cross-layer functions of the ITS station management entity into a new set of modules. These are briefly introduced; details of each module are provided into the forthcoming chapters. 3.1 IPv6 networking in the ITS station architecture: ISO ISO (CALM: IPv6 Networking) [ISO-21210] is the result of the work performed within ISO TC204 WG16 (CALM). It specifies IPv6 network protocols and services necessary to support global reachability of ITS stations (in the context of the ITS station architecture), continuous Internet connectivity for ITS stations and the handover functionality required to maintain such connectivity. This functionality also allows legacy devices to effectively use an ITS station as an access router to connect to the Internet. Essentially, this specification describes how IPv6 is configured to support fixed and mobile ITS stations (vehicle, roadside and central ITs stations) and their attached nodes. ISO doesn t define a new protocol, a new exchange of messages at the IPv6 layer, or new data structures. It defines how standard IETF protocols are combined so that ITS stations can communicate with one another using the IPv6 family of protocols. Currently, ISO supports the following features: IPv6 signaling All the basic set of IPv6 features necessary to establish communication with 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 distribute its functions into multiple nodes. The prefix is allocated statically. Stateless Address Auto-Configuration (SLAAC) [rfc4862] is used to configure the IPv6 addresses of the ITS station nodes attached to the ITS station routers (ITS station internal IPv6 interface). For mobile ITS stations, transient addresses are configured as a result of handovers (on the ITS station external IPv6 interface). 25

27 IPv6 reachability and session continuity NEMO Basic Support [rfc3963] is used to maintain IPv6 reachability at a permanent address and to maintain IPv6 connectivity when a mobile ITS station is moving between IPv6 points of attachment or is changing its 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 path over multiple access technologies simultaneously, in a mobility scenario where the end point of the IPv6 communication path is renewed each time the mobile ITS station gets attached to a new access router. The features provided by the IPv6 protocol block as specified in ISO are grouped into modules, as illustrated on Fig This separation into modules makes the specification of 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 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 features is provided by NEMO, and NEMO behaves differently for the MR and the HA). ISO specifies 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) for the definition of their operation. Those modules are: IPv6 forwarding module This module comprises basic IPv6 features (Neighbor Discovery, Stateless Address Auto-Configuration, etc) to acquire necessary IP parameters 1 NEMO Basic Support is used instead of Mobile IPv6 to comply with the requirement that and ITS station, in the most general case is made of several nodes ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 26/134

28 (IPv6 addressing) and IP next hop determination (IPv6 forwarding). It enables IPv6 to run over different lower layer technologies. It must be present in all ITS station IPv6 nodes. IPv6 mobility management module This modules comprises mechanisms for maintaining IPv6 global addressing, Internet reachability, session connectivity and mediaindependent handovers (handover between different media) for in-vehicle networks. Nothing new, this module combines NEMO Basic Support [rfc3963] and Multiple Careof Address Registration [rfc5648]. It must only be present in ITS station IPv6 nodes performing functions to maintain Internet reachability and session continuity (MR and HA) External IPv6 interface module This module comprises the mechanisms necessary to transmit IPv6 packets back and forth between the IPv6 layer in the underlying access technologies through the IN-SAP. This module performs the IPv6 address configuration and reports to the ITS station management entity the status of the IPv6 address configuration, through the MN-SAP. There is one instance of such a module for each access technology used to connect the ITS station to other ITS stations or legacy IPv6 nodes. ITS station IPv6 LAN interface module This module comprises the mechanisms necessary to transmit IPv6 packets back and forth between the IPv6 layer in the underlying access technologies (e.g. Ethernet) through the IN-SAP. This module performs the IPv6 address configuration and reports to the ITS station management entity the status of the IPv6 address configuration, through the MN-SAP. This module must be present in all IPv6 nodes of a given ITS station when the ITS station functions are distributed into separated IPv6 nodes, ITS station IPv6 nodes are linked through an ITS station internal network, referred to as the IPv6 LAN in ISO IPv6 security security The need for a module in charge of securing IPv6 communications is acknowledged in ISO 21210, but the required features are not yet defined. 3.2 IPv6 networking issues in the ITS station standards IPv6 networking issues The IPv6 Networking protocol block currently specified in [ISO-21210] is defined mostly for maintaining Internet connectivity and session continuity. This presents some limitations as explained in the following sections. Some of the missing features described below have indeed been proposed by the GeoNet European Project (see [GeoNet-D1.2]), some of which have been detailed, whereas some others were left out for future work: Inefficient routing between ITS stations As it is specified in [ISO-21210], Internet connectivity and session continuity for a vehicle ITS station are provided by NEMO Basic Support [rfc3963] (see Section??). NEMO Basic Support maintains a tunnel between a vehicular router (i.e. mobile router or MR) in the vehicle ITS station and a central router (i.e. home agent or HA) in a central ITS station. As a result of the use of NEMO Basic Support, all data packets emitted to or from the vehicle ITS station 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 station communicates with another nearby ITS station (vehicle or roadside), particularly when ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 27/134

29 the two neighbors ITS stations are on the same IPv6 wireless link, i.e., one IPv6 hop away. It is even more inefficient for communication between two neighbor vehicle ITS stations which are registered with distinct HA (e.g. in the situation where the two cars 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 the same wireless link if the same media is used to access the Internet. In other words packet transmission performance is inefficient in some communication scenarios due to the tunnel established by the NEMO Basic Support protocol. However, this tunnel is necessary to maintain Internet connectivity and reachability, so we need to provide a mechanism that allows direct routing between two adjacent ITS stations in addition to maintaining Internet connectivity and reachability. IPv6 GeoNetworking The GeoNet project has defined procedures allowing the transmission of IPv6 packets over a virtual IPv6 link established over multiple ITS stations (vehicle-to-vehicle or vehicle-to-roadside). Multi-hop routing is performed by the GeoNetworking 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 and GeoNetworking and is not yet integrated into ISO IPv6 security Although the need to secure IPv6 communications is acknowledged in ISO 21210, no mechanisms are provided to authenticate IPv6 signaling. Relation with other layers (SAP functions and parameters) The ITS station management and ITS station networking & transport layer must exchange some information so that the management entity can determine the best communication path for a given flow and provide routing policies to the IPv6 networking protocol block. To achieve these goals, the SAP between ITS station management and ITS station networking & transport layer (MN-SAP) must be defined. Currently, ISO loosely defines clauses where the IPv6 protocol block reports the status of IPv6 links to the ITS station management, and where the ITS station management requires the IPv6 networking protocol block to perform some actions. Regarding the interaction between the ITS station management and the ITS station networking & transport layer, the IPv6 networking protocol block is not yet specified in any ITS station standard. Currently the specification of the relation between the ITS station management entity and the ITS station networking and transport layer in [ISO-24102] is limited to the FAST networking protocol. However, ISO is under revision, so the necessary mechanisms are 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, the ISO 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 to some network event (interface down, new flow,...), without waiting for the management to transmit a new decision. Means are required for, on one hand a way to associate packets to a flow identifier, and on another hand specify per-flow routing policies. Seamless IPv6 horizontal handovers No mechanisms are defined in ISO to perform horizontal handovers with minimum packet loss and transparently to the applications deployed in ITS stations. Specific support functions are required to shorten the period of time necessary to divert the flow on a new communication path from one ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 28/134

30 access router to another access router from the same operator and using the same access technology. A protocol such as FMIPv6 [? ] may be deployed in the IPv6 access routers providing access to vehicle ITS stations. Seamless IPv6 vertical handovers No mechanisms are defined in ISO to perform vertical handovers with minimum packet loss and transparently to the applications deployed in ITS stations. Seamless handovers can effectively be performed using mobile edge multihoming features (such as MCoA) implemented in the ITS-S IPv6 mobile router and the ITS-S IPv6 home agent. However, specific support functions are required to shorten the period of time to divert flows from one medium or one operator to another. IPv6 multicasting No mechanisms are defined in ISO to support IPv6 multicasting, i.e. mechanisms to advertised IPv6 multicast groups, to manage group membership and to perform multicast routing, within the ITS station and between ITS stations. Dynamic IPv6 address provisioning No mechanisms are defined in ISO to describe how the IPv6 prefix to be deployed in the ITS-S LAN is provided to the ITS Station. This delegation must take into account requirements for the stability of the delegated prefix across re-initialization of the ITS-S IPv6 mobile router. This stability may be required by application or for accounting at the operator side. The stability of the delegation may also be considered if the ITS Station migrates from an ITS-S IPv6 home agent to another, for operational reasons or for network optimization considering the location of the station. IPv4-IPv6 interoperability support While all ITS sub-systems required to support IPv6 for TCP/IP-based communications, IPv6 nodes deployed in an ITS station may need to communicate with existing IPv4-only legacy ITS services 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 IPv6 connectivity, 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 the required features are not yet defined. Personal ITS station Currently this specification considers only the vehicle ITS station, the roadside ITS station and the central ITS station. However, vehicle, roadside and 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 onboard Internet connectivity provided by the ITS-S IPv6 mobile router serving the mobile ITS-S IPv6 LAN. IPv6 networking for the personal ITS station is not yet considered and shall probably be defined in coordination with ISO TC204 WG17. At a minimum, IPv6 networking for the personal ITS station would have to comply with the 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 time critical or safety-related IPv6 flows or packets are transmitted with higher priority than other IPv6 flows or packets. Once [ISO-21210] is open for revision, it is planned to specify the requested IPv6 features based on the ability of the ITS station to be mobile or fixed rather than on the role played ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 29/134

31 (vehicle, roadside, central or personal ITS station). The rationale is that the roadside ITS station may be deployed in vehicles e.g. emergency vehicles and that vehicle ITS station may be parked and act as a roadside ITS station e.g. road operator patrol vehicle parked on the emergency lane in case of accident or traffic jams ITS station architecture issues Although IPv6 networking operations can in most cases be performed independently from the ITS station management and other layers, it is necessary, in order to determine the most appropriate path for a given flow, that the IPv6 protocol block interact with the ITS station management. In addition, it must also interact with the ITS station security entities in order to secure IPv6 communications. There is thus a number of issues that must be addressed in other ITS station standard not strictly related to IPv6. These are: Application flow requirements There is currently no means to determine how a flow should be treated across the ITS station stack. This first requires to determine requirements to be applied to each type of flow. There is a variety of requirements and these include the priority, user preferences (costs, location privacy), technical characteristics (maximum acceptable end-to-end delay), regulations, security level, capabilities (geographic distribution, continuous Internet connectivity,...). Means to provide these application flow requirements to the ITS station management entity must thus be defined. Cross-layer flow management The IPv6 protocol block must be able to take decisions applying to a set of packets with the same traffic pattern (i.e. flows of packets going 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, and to apply policies in a coherent manner, i.e. a flow which is given priority at the IPv6 layer must be given the same priority at other layers. Cross-layer path management In order to select the best available IPv6 path, it is necessary to obtain information about the access technologies characteristics and application flow requirements and to monitor the current conditions of the network. All this information cannot be obtained directly by the IP layer, but the information is available at other layers of the ITS station stack. All these information must be gathered in order to decide which routing policy should be applied to a given flow at a given time. Cross-layer security management Atomic security operations such as arbitrary bit generation, hashing, signing/verification, and encryption/decryption should be performed in the ITS station security entity when such operations are requested from the horizontal layers (or more specifically security modules at each layer/protocol). In addition, the interactions between the ITS station security entity and the horizontal layers should be performed in a security mechanism/protocol agnostic way so that the behavior of the ITS station security entity does not depend on any particular type of security mechanism or protocol. This would provide more modularity and minimize development complexity of the ITS station security entity [Lee2011b, Lee2012a]. Networking protocol block agnostic MN-SAP The ITS station management entity and the ITS station networking & transport layer can exchange parameters through the MN-SAP. In order to support multiple ITS station networking & transport protocol ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 30/134

32 blocks (IPv6, GeoNetworking, FNTP,...), the MN-SAP must be defined agnostically to a particular ITS station networking & transport protocol block. The ITS station management entity must be aware about the features that are supported by all ITS station networking & transport protocol blocks but not how the features are performed. We therefore propose to redefine the MN-SAP so that it include the necessary procedures and parameters, in an abstract way, agnostic to any specific ITS station networking & transport protocol block. For instance, the ITS station management entity doesn t need to know what is the structure of an IPv6 address and what it is used for (i.e a Home Address is used as an identifier and a Care-of Address is used as a locator), it just need to know how each node is identified (node identifier) and where it is located in the topology (locator identifier). Distributed ITS station functions Networking capabilities such a IPv6 allow to distribute the functions of the ITS station in various ITS station nodes. However, this is not always considered in the ITS station standards. For instance, a mechanism is necessary to synchronize the decision taken by the ITS station management between multiple ITS station nodes when an ITS station comprises several ITS station routers. As another example, there is no mechanism allowing ITS station applications deployed in 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 presents some limitations, as discussed in Section The new needed features do not necessarily fit into one of the modules already defined in the existing ISO standard, so new modules are proposed, and existing modules are extended, whenever necessary. In addition, the relation between the IPv6 protocol block and the ITS station management entity was not well defined; we propose that a single module be in charge of this relation as it simplifies the relation between modules and removes their dependency with other ITS station standards. From our internal investigation, we concluded that the following modules are needed in the IPv6 protocol block: IPv6 adaptation agent module The ITS station architecture comprises a vertical management entity performing cross-layer functions, including functions to determine the most appropriate communication path for a given flow. It performs the interaction between 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 the processing of the MN-REQUEST actions sent by the IPv6 protocol block to the ITS station management entity and the MN-COMMAND actions sent from the ITS station management entity to the IPv6 protocol block. This includes the notification to the ITS station management entity of the status of IPv6 address configuration and the notification from the ITS station management entity of new policy rules to apply to IPv6 flows. This module is detailed in the Chapter 5. IPv6 traffic classifier module This module analyses incoming IPv6 packets and associate them to a flow identifier. This flow identifier changes the behavior of the whole IPv6 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 Discovery, Stateless Address Auto-Configuration, etc) to acquire necessary IP parameters ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 31/134

33 (IPv6 addressing) and to perform IP next hop determination (IPv6 forwarding). It forwards 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 ITS station to maintain continuous Internet connectivity and reachability simultaneously over multiple access technologies, session connectivity and media-independent handovers, in situations where the ITS station is composed of multiple ITS station hosts and routers. It comprises features such Network Mobility (NEMO) Basic Support and Multiple Care-of Addresses Registration (MCoA) and is detailed in Chapter 8. IPv6 adhoc networking module This module performs the functions required at the IPv6 layer for direct communications between all IPv6 nodes attached to neighboring ITS stations (particularly vehicle ITS stations and roadside ITS stations). It also allows the vehicle ITS station to determine whether a roadside ITS station can be used or not to access the Internet. It comprises INPD, a new protocol specifically designed for Cooperative ITS and is detailed in Chapter 9. IPv6 over GeoNetworking module This module comprises features to combine IPv6 networking together with GeoNetworking (IPv6 GeoNetworking). It is executed on an IPv6 external interface with specific characteristics. This module is partly detailed in Chapter 10. IPv6 security module This module performs the functions required at the IPv6 layer to secure IPv6 communications. It interacts with the ITS station security entity via 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 IPv6 layer for multicast communications, i.e. mechanisms for IPv6 multicast group advertisement, IPv6 multicast group membership and IPv6 multicast routing. It comprises MLD and is partly detailed in Chapter 12. IPv4-IPv6 transition module. This module provides backward compatibility with legacy nodes and access networks not yet deploying IPv6. It comprises DS-MIPv6, L2TP and OpenVPN. [rfc5555] allows IPv6 nodes to configure an IPv6 address when Internet access is provided by an IPv4 access network. Alternatively, solutions such as L2TP or OpenVPN may also be used. L2TP builds a PPP connection between the an IPv6 node and an IPv6 access router. This connection is presented to upper layer as a normal PPP network IPv6 interface. Header and data compression may be used over the PPP link in order to reduce the overhead due to L2TP. This module is partly detailed 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 not yet detailed in the present document. IPv6 host module This module performs the minimum set of IPv6 host functions. t comprises features such as Neighbor Discovery in host mode. This module is not yet detailed in the present document. IPv6 internal interface module In ISO 21210, this module was named ITS-S IPv6 LAN Interface. It is in charge of the configuration, at the IPv6 layer, of the IPv6 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 32/134

34 interface (e.g. IPv6 addresses), and of executing relevant functions to be executed on the link on which this interface is configured. The internal IPv6 interface is used for communication between ITS station nodes composing the same ITS station. This module is not yet detailed in the present document. IPv6 external interface module This module 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 executed on the link on which this interface is configured. The external IPv6 interface is used for communications with a node not belonging to the same ITS station (i.e. to other ITS station nodes, or to legacy IPv6 nodes). This module is not yet detailed in the present document. 3.4 ITS station management entity design The ITS station architecture proposes a vertical management entity performing cross-layer functions. Cross layer functions are essential for the determination for the best communication interface and next hop (path) since such a wise selection can only be performed once the media characteristics, the application flow requirements and the current network conditions are known. In this respect, ITS station management standards also present some limitations, given the limitations of ISO discussed in Section and the need for new modules discussed 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 layer and 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 communication paths for a given flow and provides routing policies to the network layer. Each flow is identified by a flow identifier, that is used across the entire ITS station stack. Requirements are applied to each flow. This module is partly detailed in Chapter 4. Policy Exchange Routing policies highly depends on choices of the vendor, constructor, maintainer. This may imply contradictory policies on each ITS Station node. Flows may be routed in an asymmetric way, leading for some kind of applications to misbehave, 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 IPv6 protocol block must be performed via the MN-SAP, in a network protocol agnostic way so that the behavior of the management entity does not depend on any particular network protocol. Procedures needed to exchange information between the ITS station management and the ITS station networking & transport layer are defined in ISO and need to be extended in order to include the new procedures and parameters necessary for path management, flow management and policy exchanges. This is detailed in Chapter 14. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 33/134

35 3.5 Open Issues D2.2: Preliminary System Specification All the features highlighted in Chapter 3 have not yet been defined or fully defined. Other limitations have also been identified and will be investigated, and the architecture designed will be brushed up if needed. Open issues includes: Asymmetric path selection; Multiple routers: the ITS station may be connected to the outside word through multiple ITS-S routers, for instance via a router providing 11p and 11n, and a nomadic device 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 geographical area (GeoArea). Readers are invited to follow the progress of the ITSSv6 project and to refer to deliverable D2.4 Final System Specification to be published in February ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 34/134

36 CHAPTER 4 Path and flow management In this chapter, we describe procedures within the ITS station management entity (SME) to determine what are possible communication paths and to determine which flow should be routed to which communication path. The SME collects information from all the horizontal layers and gathers it into several databases. It then determines what are the available paths and issues routing policies to be applied to communication flows. These policies are transferred 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 reference architecture for Cooperative Intelligent Transportation Systems (C-ITS). These are very important to understand the remaining parts of this document. Paths and flows are defined from the view point of an individual ITS station i.e. different ITS stations have a different view on the available paths and ongoing flows. As a result, path and flow identifiers are unique within an ITS station. Path: a path is defined as a sequence of adjoining nodes and links between two controllable communication end points, from a starting controllable communication end point to the furthest controllable communication end point towards a or destination node or a set of destination nodes (See Figure 4.1).The controllable communication end 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 are forwarded to on the path whereas the anchor is the furthest controllable end point. A locator identifies the topological network location of each controllable communication end point. Another important parameter of the path is the Communication Interface (CI) used to reach the next hop. As such, the locator on the local ITS station s side identifies the topological location in the network where the CI is attached to while on 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

37 Locator(s) are allocated to each CI N A E N A E The Paths from this ITS-S point of view Local routing domain N E Controllable ITS Station other nodes Communication Interface Roles of ITS-S E N A End Point Next hop Anchor 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 defined by 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 a given path or a set of available paths 4.2 Overview The procedures to determine what are the possible communication paths and to determine which flow should be routed to which communication path are divided into distinct functions within the SME: Path management is the process of obtaining various information about the controllable end points where packets will have to be routed and keeping track of all the candidate and available paths. This information is obtained from horizontal layers using MN-Request.STAGeoNot, MN-Request.STATopoNot, MN-Request.STAServNot, MN-Request.PathNot, MN-Request.PathMetricNot for the information coming from the SNT. If not provided by the SNT, the path status could also be estimated internally from collected statistics. In the other direction, the SME informs the SNT using MN-Commmand.PathMNGT and MN-Commmand.STAServDiscov. This function is detailed in Section 4.3; Flow management is the process of keeping track of the requirements applying to all application flows and collecting flow statistics. The requirement are obtained from the application or facilities layers using MF-Request.ITS-S-Appl-Reg while statistics are obtained from the SNT using MN-Request.FlowStat. On the other direction, flow statistics are requested by the SME to the SNT using MN-Command.FlowFeedback; ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 36/134

38 Path selection is the process of determining the most appropriate path(s) from all the candidate 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.FlowClassificationRule and MN-Command.FlowPolicy; These functions require information from various layers. The SME collects information and monitors the current state of the network (via the MN-SAP), the characteristics of the access technologies (via the MI-SAP), flow requirements expressed by applications (via the MA-SAP) or the facilities (via the MF-SAP), and other information maintained locally in order to determine routing policies to be applied to application flows, given the flow requirements, the current status of the network and access technologies characteristics. This is illustrated on Figure 4.2. The collected information is recorded in various tables: Application ITS Station Application Requirement Management Facilities CAM DENM LDM SAM Position Network & Transport Path / Flow Management Decision module MN- SAP Access NEMO NDP p GeoIP -SAP IPFilter Routing GeoNetworking Wifi IP ITS Local Network Other Protocols 3G Strong focus Consideration of parameters 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 of the local ITS station while the neighbor ITS station information table is defined for maintaining the status of the other ITS stations that are involved in the path determination (i.e MR, AR, CN, etc). This latter table will thus not record information about all ITS stations in the neighborhood of the ITS station. Details about these tables are presented in Sections 4.6 and 4.7; The path information table: records various information about all existing or possible paths. Details about the table are presented in Section 4.8. The flow requirement table records performance requirements to be applied to each application flow; the flow information table records networking parameters used to ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 37/134

39 identify each flow; the flow statistics table records various statistics about each flow and how flows are classified and routed by the SNT; the flow policy table records policies generated by the SME. The last table allows to link flows to paths. Details about these tables are presented in Sections 4.9, 4.10, 4.11 and Application ID Flow Type ID Flow requirement table Identifier Management Parameter Flow Information table Link between ID and database Flow Statistics table Flow ID Flow Policy table VCI ID and VCI list are defined in [ISO ] Path ID VCI ID Path Information table VCI list Node ID Local ITS-S Information table Neighbor ITS-S Information table Figure 4.3: Relation between management parameters and identifiers Figure 4.3 shows the relation between these tables and the main layer from where the information is obtained. Figure 4.4 shows the information flow between the path selection manager in the SME and the horizontal layers. The functions offered by the SME to manage paths and flows (path management, flow management, path selection) are described in the forthcoming sections, followed by the description of all the tables. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 38/134

40 SAP Function parameter Information SAP Management Flow requirement table MF- SAP MF-REQUEST ITS-S-Appl-Reg [ISO_24102] Flow req & Flow stat Flow requirement list MF- SAP Facilities Flow Information table Flow statistics table MN-REQUEST FlowStatNot Flow Statistics ITS-S information Network & Transport Flow Policy table ITS-S Basic info Local ITS-S Information table Neighbor ITS-S Information table MF- SAP MN- SAP STAGeoNot STATopoNot STAServNot PathNot Geographic Position Topological Information Service Path Information Path Status MN- SAP Path Information table Path and Flow Management MI- SAP MN- SAP PathMetricNot MI-REQUEST Event [ISO_24102] MN-COMMAND PathMNG STAServDiscov FlowClassRule Network Metric Interface Path Infomation ITS-S Information Flow Flow Classification Rule MI- SAP MN- SAP Access Network & Transport FlowPolicy Flow Policy FlowMonitor Flow Statistics Figure 4.4: Cross-layer information flow for path and flow management ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 39/134

41 4.3 Path management D2.2: Preliminary System Specification Collected information maintained in the SME is recorded into various tables. In total, all the collected information is divided into seven tables, that could be further divided into three categories, i.e. information about ITS stations, information about paths and information about flows. The process of path management starts from the perception of network elements in the network where the ITS station connects. First, as can be seen in the Figure 4.5, the information of the self ITS station is recorded in the local ITS station information table. And then, when the ITS station connects to a network, the ITS station finds the neighbor ITS station with some exchange of messages (neighbor discovery mechanism). Obtained information 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 station 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 in the corresponding neighbor ITS station information table entry. The ITS station may discover neighbor ITS stations that provide anchor service with signaling of some network layer protocols between the ITS stations. N1 A1 VCI1 Anchored path S N2 A2 VCI2 Direct path Management Parameters Local ITS-S info table S Neighbor ITS-S info table D1, D2, N1, N2, N3, A1, A2 N3 Optimized path Path info table VCI1 N1 A1 D1 N1 A2 D1 VCI2 N2 A1 D1 D2 D1 N3 A1 D1 N2 A2 D1 N3 D2 etc. Controllable ITS Station other nodes Communication Interface Roles of ITS-S E N A End Point Next hop Anchor Figure 4.5: Controllable communication points Path 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. We refer as the anchored path the path via at least one anchor that does not provide any route optimization service (typically to the Internet) as illustrated in Figure 4.5. In contrary, the optimized path is a more direct path for reaching a given destination (an anchor may not be needed for the optimized path). On the other hand, a more direct path that does not go beyond the local routing domain is called a direct path. Thus a direct path does not contain any next hop nor any anchor (except for containing an ITS station which have access service without using the service.) In vehicle ITS station situation, the packet via the direct path is often forwarded by intermediate vehicle ITS stations using a multi-hop Vehicular Ad-hoc Network (VANET) routing protocol without depending on any infrastructure (neither roadside infrastructure ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 40/134

42 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. In many situations there are multiple paths reaching to a given destination node, using different access technologies, different access networks (roadside access network, public access network, cellular operator network), and passing through different administrative domains (e.g. urban WiFi operators C and D). Packets sent over different paths to the same destination node experiment different characteristics (delay, throughput, security level, etc.). And eventually, the SME receives the notification from the network layer protocols that a path is established and became ready-to-use (Available path). All the information about candidate paths and the available paths is recorded in the path information table. All the paths are identified by a unique identifier called Path ID. In summary, the path information table provides the most up-to-date status of the paths by the notification of the network layer. For intelligent path selection, it is also important to predict the candidate path and its characteristics. The prediction can be performed with, for example, the help of statistical analysis, cross-layer information, information from sensors, etc. SME must thus maintain the following two types of path information so that the path selection manager takes a decision based on both the most up-to-date status and the 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 each path depend on path management mechanism and out of focus of this document. Router Mobile operator Base Station Internet Anchor Anchored path 3G Optimized path wifi Locator Router Router Host Host Router 11p Roadside VANET Direct path Vehicle ITS Station Vehicle ITS Station Router Vehicle Figure 4.6: Possible paths between two vehicle ITS stations ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 41/134

43 The SME should be aware about the surrounding ITS stations (nodes) in order to comprehend the status of the network around it. Especially, the SME should be aware about the services provided by each neighbor (e.g. vehicle ITS station able to relay information to other vehicles, roadside ITS station providing Internet connectivity, etc.) This is essential for determining the appropriate path where to route the packets. This information is referred to as the ITS station information and is recorded in two separate tables, the local ITS station information table and the neighbor ITS station information table. In addition, it is also important to comprehend the network status. The SME stores in the path information table information about all the possible paths. In order to select the 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 and to maintain accurate information. All these parameters are very important to determine what 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 local ITS station. Details about the table are presented in Section 4.6. This table is updated when MN-Request.STAGeoNot, MN-Request.STATopoNot, MN-Request.STAServNot are received by the SNT. Other information could be obtained by the ITS station facilities but is not currently defined. Neighbor ITS station information table: records various information collected from 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 obtained by the ITS station facilities but is not currently defined. Path information table: records various information about all existing or possible paths. Details about the table are presented in Section 4.8. This table is updated when MN-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 obtained through the M*-SAP are expressed at the SME in a protocol agnostic fashion (e.g. an IP address 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 ITS station, and ITS stations are of different types. The SME treats all ITS stations the same way. 4.4 Flow management Flow requirements In order to determine on which path a given flow should be routed, the SME must first know which path satisfies the network performance requirements for that flow. For legacy applications, 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 to the SME. This would require new mechanisms or modification of existing mechanisms in the ITS station set of standards, particularly in the situation where the ITS station functions are distributed in several hosts and routers. This applies to both applications residing at the ITS station application layer and applications residing at the ITS station facilities layer: ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 42/134

44 From a flow management view point, ITS station facilities processing broadcast messages e.g. DENM, Co-operative Awareness Messages (CAM), SAM are indeed considered as applications. CAM [ETSI-TS ], DENM [ETSI-TS ] and SAM [ISO ] must thus provide their flow requirements to the ITS station management entity. This would be done via the MF-SAP. While some applications residing at the ITS station application layer are fully relying on 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 must also provide their flow requirements to the ITS station management entity. This would be 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 of requirements to be applied to each application flow (note that there could be multiple flow types 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 stakeholders may prefer a specific protocol stack (e.g. BTP/GeoNetworking/11p) when it is available while IPv6 would only be used otherwise. Other may avoid a specific media Flow registration Entries in the database are identified by a flow ID unique to the ITS station. The ITS station management 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 SAM may be well-known and thus registered into some central authority with pre-determined values, identified by a flow ID Flow statistics In order to take relevant path selection decisions, the SME needs to have a view on how they are applied in the SNT. This need is covered by flow statistics. Flow statistics gather the list of flows that transit through the network, with associated data about their load, and the way they are handled by the SNT. Statistics are provided for any registered or not registered flow. The SNT reports them depending on its matching capabilities. For both not registered and registered flows, it may 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 output for already defined flows. Foreach flow, three type of data are retrieved: Network statistics: actual statistics about number of packets and throughput of the considered flow. Classification information: informs the SME how the flow is actually handled. It informs to which Flow Identifier (FlowID) the flow was mapped, and to which Path Identifier (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. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 43/134

45 The SME regularly probe the SNT for updated statistics. These statistics are stored in the flow statistics table. Then, they are used by the path selection process to adjust network load. 4.5 Path selection Flows mapped to paths Selecting a path is essentially the process of matching a given flow to a path according to application flow requirements and the current characteristics of all the available paths. The path selection can be made based on the information stored in the flow requirement table and the characteristics of the paths stored in the path information table. The decision is taken based on multiple criteria (e.g. delay, bandwidth or stability). The path selection process must consider: CI: selecting a path is mostly equivalent to selecting a CI since the communication characteristics of a path are mostly determined by the media type of CI including data rate, cost, reliability, security, power consumption, etc. Next hop: selecting a path depends on the selection of the next hop, because two paths leading to the same controllable communication end point are different when a CI is connected to different next hop; Type of path: as highlighted on Fig. 4.6, paths could be of very different types. The anchored path is usually significantly longer, but may also be considered more stable and more secure. Under certain circumstances, paths of a given type may be available very 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 geographically distributed locations. Selecting the most appropriate one could improve the performance, particularly in terms of delay. However, a given anchor often implies peculiar administrative and security policies which take precedence over the performance. In the situation of a vehicle ITS station, the selection of the access router is important especially 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 communication end point i.e. the anchor; when it is reached directly, it is the first controllable communication end point, i.e. the next hop. In the situation where the controllable path starts and completes at 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 of network and access technologies status, and application flow requirements. SAPs and information tables are designed so as the SME gets all necessary information. If so, the SME is able to enforce its decisions to the SNT on a per-flow basis. This principle allows to define policies according to the destination ITS station, the source ITS station, the application, or some identified traffic from an application. To each flow are applied distinct policies Flow policies Flow policies have to be built so that these mostly comply with application flow requirements and optimize network and hardware resources. Finally, this decision should be made in an environment where both ITS station aware and legacy applications evolve. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 44/134

46 As a result of performing the path selection, flow policies (rules) are communicated by the SME to the SNT using MN-Command.PathMNGT. These rules are configurable by stakeholders, e.g. users, device vendors, service providers, OEMs, car manufacturers. As such, these rules are competitive factors among stakeholders, so the definitions of these policies are outside the scope of any International Standard. Default routing procedures could be pre-registered in any manner the manufacturer wishes to implement or could be performed based on the source and destination of the flow and other parameters. Default settings are particularly important so that flows originated from legacy applications for which requirements 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 entries are 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 of the movement of the station on the paths managed by the ITS station, while the vehicle type as defined in [ETSI-TR ] could be useful to qualify the ability of the local ITS station to relay packets not interned to itself. The second category is the topological information, currently limited to the locator which indicates the location of the locator ITS station in the network topology. It is an important 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 ITS station. The geographic information includes geographical position (latitude, longitude and altitude) and movement information (speed and direction). It is used to compute the distance to 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 local ITS station, like for example, the ability to preserve sessions while changing its point of attachment, the ability to maintain connectivity simultaneously via multiple CIs, or the ability to provide location privacy support. Some of the Information is maintained internally within the SME, while other could be obtained from various layers. The topological and geographical categories are dynamic information. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 45/134

47 Basic Geographic Parameter Station ID Station type Vehicle type Description Identifier of ITS station. Preferably globally unique. See details in [ISO ]. Type of ITS station. ex) Vehicle ITS-S, Roadside ITS-S (Optional) Type of vehicle. ex) car, bus, taxi, motor cycle Latitude 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. 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 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 46/134

48 4.7 Neighbor ITS station information table Basic Topological Geographic Parameter Station ID Station type Vehicle type Locator Scope Description Identifier of ITS station. Preferably globally unique. See details in [ISO ]. Type of ITS station. ex) Vehicle ITS-S, Roadside ITS-S Type of vehicle. ex) car, bus, taxi, motor cycle Indicates the location of the ITS-S in the network topology. In the Internet, it is the network part (first 64bits) of an IP address that indicates the network topology location of the node. 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 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. 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 to the local ITS station information table. It could be obtained from various layers. All entries are 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 of the movement of the station on the paths managed by the ITS station, while the vehicle type as defined in [ETSI-TR ] could be useful to qualify the capability of a neighbor ITS station to relay packets not intended to it. The second category is the topological information, currently limited to the locator which indicates the location of the neighbor ITS station in the network topology. It is an important 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 includes geographical position (latitude, longitude and altitude) and movement information (speed and direction). In addition to the basic geographic information, the SME can obtain more detailed vehicle status information from the facilities layer, using LDM [ETSI-TR ], CAM [ETSI-TS ] and DENM [ETSI-TS ]. Also the SME can calculate relative information like distance to the surrounding ITS stations with its own geographic information. The forth category are services, instead of capabilities recorded in the local ITS station information table. In the network, a service is often provided by neighbor ITS stations; it is ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 47/134

49 thus logical to bind the service information corresponding to a given ITS station information entry. Multiple service can be provided by same neighbor ITS station. Examples of services meaningful at the network layer include the ability for e.g. a roadside ITS station to offer Internet connectivity (free or paid), to allow vehicle ITS stations to route relay packets to other vehicle ITS stations, etc. Other services not useful for networking may also be listed here. 4.8 Path information table This section describes how the three types of information in the path information (CI information, path status and path metric) are managed in order to determine candidate paths. The list of the parameters is shown in Table 4.3. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 48/134

50 CI Path Status Metric Parameter Description Link ID Unique identifier of a Virtual Communication Interface (VCI)/CI where the path starts from. See [ISO ] for details. Media type The kind of a wireless communication interface is used. CIclass(15) 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 Consumption Power consumption of the interface when the interface is transmitting data 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 Locator Next hop Anchor Reachability Capabilities Status Payload size Delay Hop Unique Identifier to identify the path Identifier indicates the topological location of the ITS station in the network. ITS station on the path that acts as a border router when packet goes beyond the network managed by a local routing protocol. ITS station that provides Locator registration function to the ITS station. Topological distance indicator from the CI. on-link, Local Network, Extended Local, ITS domain, Global Network, TBD 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 of the path. 0: not available 2: ready to be used 4: going to up 1: being used 3: potentially ready 5: going to down Size of payload for a packet using the path. A trip time that the wireless interface has, and actual round trip time to reach to the node in the destination scope 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 notified from the access layer to the management entity via the MI-SAP. 52 CI parameters are specified in [? ] as shown in Table 4.4. "I-Parame.No" indicates the identifier of the parameters. It is given as a parameters of the MI-SET and MI-GET command to respectively read and write these parameters. The SME can access these parameters at arbitrary time using MI-GET, however some parameters are mandatory to be maintained in the management entity, which is called VCI performance parameter list (VCIperformList) (See details in [ISO ], bold characters in Table 4.4). These are the actual values of performance parameters values of VCIs and the information is kept about all the VCIs in the management entity. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 49/134

51 VCIperformList is also useful to see the path performance. Beside VCIperformList, we list important parameters from access technologies in Table?? ((Number) after CI parameter name indicates M-Param.No in the Table). Media type, data rate, cost and reliability are CI 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 parameters that characterize the path including the ITS Station information that is in the middle of the path (AR, HA, MR and CN), capability of mobility support, topological locator of the starting point, availability of the path, reachability of the path and etc. Path status is provided by network parameters that come from MN-SAP. Some paths can be created from same CI using different routing protocols, different next hops and anchors. These paths are identified by path ID. Topological locator indicates the topological location of the node and the access network where the CI is attached to. The reachability field indicates which part of the network is reachable beyond the neighbor ITS station. In principle, just after configuration of a VCI, the VCI cannot reach beyond anywhere before the network layer configurations, except for On-link. As network configuration progresses, the path completed reachability extended to reach more nodes beyond On-link. The state is stored in the reachability field as On-link, Local Network, Extended Local, 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 a local routing protocol. In vehicle ITS Station case, it is the reachability to the vehicle and roadside ITS Stations in a wireless multihop vehicular ad-hoc network. Some routing protocols enable multihop communication. Extended Local Reachability to the ITS station internal nodes of the neighbor ITS stations in the Local Network. Typically, the ITS station internal nodes attached behind an ITS station router in a vehicle or an ITS station router in roadside ITS station do not have a routing function. A protocol is needed to exchange the station internal prefix in order to reach nodes attached to the neighbor ITS Station. ITS domain Reachability to central ITS stations that provide ITS services. Depending on the security policy or administration policy, ITS domain may not provide the reachability to the Global Network. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 50/134

52 MNN ITS-S Information - Identifier - Topological information - Geographical information - Service information Path Information - Communication Interface - Path status - Metric MR CN AR CN Wireless Wired S On-link Local Network Extended Local ITS domain Global Network AR Anchor Figure 4.7: Network around vehicle ITS station Global Network Reachability to all the other nodes in the connected network. To enable global reachability with moving environment, session continuity capability may be required. Note that the reachability may not be established in the above order (on-link Local Network Extended Local ITS domain Global Network). Some CI may acquire Global Network 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 management 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 paths are calculated in the management entity from the combination of the entries contained in 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 shown below. The lifetime of the path is maintained as the estimated starting time and ending time of 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 the history records when the path became available and the ending time is the estimated time of unavailability. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 51/134

53 ready to be used The path is ready to be used. When the path is in this status, the starting time is the history records when the path became available and the ending time is the estimated time of unavailability. potentially ready The path potentially exists but it is not managed yet. i.e. Path selection manager is aware of the possibility of the path, however it is not sure the path could 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 starting time is the estimated time of availability and the ending time is the estimated time of unavailability. going down, The path is going to be unavailable. When the path is in this status, the starting time is the history records when the path became available and the ending time is the estimated time of unavailability. not available. The path is unavailable. When the path is in this status, both the starting time 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 number of hops. To obtain the propagation delay, same measurement is needed. The payload size is often determined by the underlying technologies. For example, since wireless interfaces have specific 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 by measurement, 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 of application flow requirements. Entries are identified by Flow type ID. The existing Application requirements list (ApplReqList) defined in [ISO ] enable the CI selection but is not sufficient for path selection. The parameters are notified to the SME using MF-REQUEST ITS-S-Appl-Req. Only the following four parameters are specified as ApplReqList: Data rate, Cost, Network protocol support and Type of CI. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 52/134

54 Generic QoS Communication Parameter Flow Type ID Application ID Priority Description and Examples globally registered or locally registered unique ID in the ITS-S, Application classes (Non-ITS aware, ITS aware (ITS-AID)) A number that indicates the priority of the flow Data rate Minimum average data rate requested at the MI-SAP in 100 bit/s. Corresponds with I-parameter 6. 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 Monetary cost 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) Corresponding module Security services Maximum acceptable cost of the link-usage in terms of money. Corresponds with I-parameter 17. (optional) Corresponding CI type, and Corresponding Network protocol modules 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 of ongoing flows. Entries are identified by the Flow ID and are linked to the flow requirement table 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 into account. Particularly, the SME only considers paths which can reach the destination node. The whole table is transmitted to the SNT for performing traffic classification. The protocol-specific information is passed by the application or by the SNT, through MN- Command.FlowStatistics. It is only interpreted by the network layer. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 53/134

55 IDs Protocol-agnostic Parameter Flow ID Flow Type ID (Traffic Class ID) Communication Mode Destination Source Protocol Protocol Information Description and Examples Unique identifier for the flow Requirements for the matching flow Classification issued for the matching flow Communication mode used by the matching flow (Node, Group, or GeoArea) Destination of the matching flow (Node ID, Group ID, or GeoArea ID) Source ITS station Node ID of the matched flow. Networking protocol ID of the matched flow 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 ongoing flows. The SME may request these statistics from the SNT. These statistics would provide the SME a picture of the network status and the ability to adjust its own decisions to actual traffic. The SNT reports statistics at an arbitrary level of preciseness. It reports one or several statistics per Flow ID. Depending on its matching capabilities, the SNT may give a more detailed view if it detects that several network flows are indeed matched to the same Flow ID. This situation can occur if a Flow ID is defined using wildcard parameters, or if a traffic does not belong to any Flow ID. Consequently, the flow information may be reused by the SME to build more specific policies for a particular traffic. This way, the SME is able to overload existing flows and policies by new ones, without relying on flow registration from applications. It is able to manage 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. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 54/134

56 Flow information IDs Stats Parameter Communication Mode Destination Source Protocol Protocol Information Flow ID Path ID Datarate Packets per seconds Description and Examples Communication mode of the reported connection (Node, Group, or GeoArea) Destination of reported connection (Node ID, Group ID, or GeoArea ID) Source ITS station Node ID of the reported connection Network protocol ID of the reported connection Protocol-specific information, provided by network. It is not computed nor used by the management. Flow Identifier currently issued for traffic from this connection Path currently used for traffic from this connection Datarate of this connection in bits/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 the SME and transmitted to the SNT. Entries of this table are indexed by a unique pair of Flow ID,Path ID (TrafficClass ID,Path ID). One Flow ID (TrafficClass ID) may be routed to several interfaces, with a given level of preference. The priority field is the preference of a policy among others. Parameter Flow ID (TrafficClass ID) Path ID Priority Description and Examples Unique identifier for the flow (Classification of the flow) Path to use for the flow Priority of this policy Table 4.8: Flow policy table ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 55/134

57 CHAPTER 5 Module IPv6 adaptation agent 5.1 Overview The IPv6 adaptation agent module is in charge of managing the relation between the IPv6 networking protocol block and the ITS station management entity (SME) as illustrated in Figure 5.1. This relation is required for path and flow management within the SME in order to determine what are the available paths, which one is preferred for a given flow, given the application flow requirements, network and access technologies characteristics and to provide rules to be applied to a given flow at the level of the IPv6 networking protocol block (see Chapter 4). Decision module Management ex) Path Selection Manager Flow Selection Manager MN- SAP Network & Transport MN-REQUEST MN-COMMAND IPv6 Adaptation Agent Event notification Action request ex) Routing, Addressing, NDP, NEMO, INDP IPv6 Network Protocol Block Event Action Figure 5.1: IPv6 Adaptation Agent Relevant events within the IPv6 network protocol are notified to the IPv6 adaptation agent. The protocol specific parameters in the event notification are translated into the protocol agnostic parameters and they are sent to SME using MN-REQUEST. The IPv6 adaptation agent processes the actions requested by the SME using MN-COMMAND and 56

58 converts them into actions meaningful at the level of the IPv6 networking protocol block and passes them to other IPv6 modules. The procedures and parameters exchanged between the SME and the IPv6 protocol block are defined in Chapter 14 (MN-SAP). The mapping between the abstract parameters recorded in various tables within the SME and the corresponding parameters used within the IPv6 networking 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 Section 5.5 whereas the management of paths within the IPv6 networking protocol block is described in Section 5.4. The relation between the IPv6 adaptation agent and other IPv6 modules is outlined in Section??. 5.2 Parameters maintained at the network layer Parameters maintained at the IPv6 layer Locator and identifier The network topology locator of an ITS station IPv6 node is obtained from the IPv6 address configured on each of its Communication Interfaces (CIs). It corresponds to the first 64 bit of the IPv6 address i.e. the network ID part of the address while the last 64 bits form the node identifier and correspond to the CI identifier. As each ITS station node could have different addresses (e.g. one for each CI or even multiple per CI if a CI is connected to multiple networks 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 station must be idenfified. The ITS Station Internal Network Prefix (IINP) indicates its position in the network topology. More precisely, it is the locator of all the ITS station nodes on the CI attached to the ITS station internal network. Considering the entire ITS station, the locator of the ITS station corresponds to locator of the ITS station router on its CI. Since there could be multiple CIs and multiple ITS station IPv6 nodes, an ITS station router generally has multiple locators. There is thus a distinction to be made between the network ID of a specific CI that could vary according to the network where it is attached to (as a result of mobility or network reconfiguration without moving) and the network ID corresponding to the IINP. The latter indeed plays the role of a unique identifier and can thus be used to identify the ITS station i.e. the ITS station ID. Though usually configured for a long period of time, this ITS station ID may be changed as a result of network reconfiguration and can only be used as a nonpermanent ITS station ID. It can be used for routing, but not as a unique identifier for the lifetime of the equipment. When mobility support protocols are used to maintain network connectivity, multiple addresses are configured on the IPv6 external interface(s). The Home Address (HoA) is normally used to identify the node while the temporary Care-of Address (CoA) is used as to identify the network where it is currently attached to. In such a situation, the network ID part of the CoA is the locator of the ITS station IPv6 node on the CI on which this address is configured, while the node ID part only identifies the CI. In addition, the network ID part of the HoA is the locator of the ITS station IPv6 node when at home. When using NEMO for mobility support, the ITS Station Internal Network Prefix (IINP) corresponds to the Mobile Network Prefix (MNP) and serves both as the ITS station identifier and the locator of alll MNNs, on the interface attached to the ITS station internal prefix. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 57/134

59 These topological information are notified, whenever necessary; to the SME using MN- Request.STATopoNot Service The service field is a set of flags that indicates the service that could be provided by the neighbor 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 by an 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 in the IP networks. An ITS station can discover the AR by Router Solicitation (RS), Router Advertisement (RA) or Dynamic Host Configuration Protocol (DHCP) messages. The results of the messages are often stored as a default gateway in the IP routing table. These service that 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 be marked at the same time. Since an ITS may provide multiple service, the service information is recorded with 64bits flags. The other flags are reserved for future usage. The service can be 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 the path. They are provided from the interface between the management entity and the access layer (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 configured to 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 locator is 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 next hop is also maintained in the routing table as a default gateway and can be obtained by RA and DHCP. The next hop is an AR in the case where the correspondent path goes to infrastructure, and it is an MR in direct V2V communication. In the NEMO mobility management module,, the anchor corresponds to the HA. The HA address is maintained in the HA list and can be obtained by Dynamic Home Agent Address Discovery (DHAAD), Binding Update (BU) and Binding Acknowledgement (BA). Anchor field indicates neighbor ITS station provides a location registration service to mobile ITS Station to support mobility. The Next hop and anchor parameters are linked to an entry 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 reachability, respectively. Some reachability information is also maintained in the routing table. For example, the routing entries added by some routing protocol indicate the reachability to the network. Local Network reachability is enabled by VANET routing protocols (e.g. GeoNetworking). Extended Local reachability is obtained by IPv6 Internal Network Prefix Discovery (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 locator registration to an anchor. In NEMO, reverse reachability capability is acquired by the message exchange of BU and BA between HA and MR. The result of the message is stored in Binding ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 58/134

60 Update List (BUL) in NEMO. QoS, multicast for group and multicast for GeoArea are also examples of the capabilities. The path can have multiple capabilities at the same time, thus the 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 parameters for the path status. Payload size is determined with MTU and header size. For example, in the case that the path is established with GeoNetworking, IP and NEMO over Wifi interface, the payload size is 1340 Bytes and can be calculated by equation 5.1, where MT U of wifi interface is 1500 Bytes, header size of GeoNetworking is 80 Bytes, header of IP is 40 Bytes, and header of NEMO encapsulation is 40 Bytes. P ayload = MT U GeoNetworking IP NEMO (5.1) To obtain the propagation delay, same measurement is needed, and the number of hops is obtained by measurement, or provided by some routing protocol. Path metric information are notified using MN-Request.PathMetricNot 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 ITS stations with the accuracy indicator and the time stamp are maintained in the location table. These parameters are exchanged by the beaconing and the location service. Relevant information is notified to the SME by MN-Request.STAGeoNot. 5.3 Mapping between management and IP parameters MN-REQUEST function parameters and corresponding events Table 5.1 shows the mapping between the MN-REQUEST function parameters (detailed in Chapter 14) and the events occuring within the IPv6 network protocol block MN-COMMAND function parameters and corresponding actions Table 5.2 shows the mapping between the MN-COMMAND function parameters (detailed in Chapter 14) and the action in the IPv6 network protocol block. When the path selection module takes a decision to establish a path, the decision is notified from SME to the IPv6 adaptation agent using MN-Command.PathMNG. Then the 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 path establishment (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 an action for service discovery to the IPv6 adaptation agent using MN-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 protocol block. ITS station sends location service request for geographic information discovery. In the case that the ITS station needs more appropriate anchors, it sends Dynamic Home Agent Address 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. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 59/134

61 MN-REQUEST Protocol Examples of corresponding events STAGeoNot GeoNet working Reception of the geographic information of a neighboring ITS station by beaconing or location service reply STATopoNot NDP Reception of the topological information of a neighboring ITS station by router advertisement or neighbor advertisement INPD Reception of the topological information of a neighboring ITS station by INPD advertisement DHCPv6 Reception of the topological information of a neighboring 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 the ITS station that have the locator registration service. PathNot Address ing INDP NEMO Configuration of a link-local IPv6 address. It means on-link reachability is enable from the CI Reception of INDP advertisement. It gives the information about the reachability to extended VANET Success of locator registration gives the information about a ready-to-use path with reverse reachability is established PathMetricNot NDP Reception of a router advertisement that contain the MTU information NEMO Establishment of MR-HA tunnel. It reduces 40 bytes of MTU because of the NEMO header. Table 5.1: Mapping between Events in IPv6 Network Protocol Block and MN-REQUEST 5.4 IPv6 path management Procedure Figure 5.2 shows how path selection is performed from the moment that a CI becomes available. 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 to top in the ITS station reference architecture. [ISO-21218, ISO ] describe the initial part of the procedure and message exchange via MI-SAP. (0) A CI s power is turned on (1) The Interface Management Entity (IME) registers the CI identified by an unique identifier, and the Communication Interface Management Adaptation Entity (CIMAE) notifies the event to the SME using RegReq. (2) IME may perform Cross-CI prioritization as an optional procedure to synchronize transmission of multiple CIs based on user priority. The event is notified from CIMAE ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 60/134

62 MN-COMMAND Protocol Examples of corresponding actions PathMNG Address ing NEMO Configuring a new CoA Establishing MR-HA tunnel sending BU from a selected CoA to a selected HA address STAServDiscov NDP Sending a router solicitation to discover ITS station that have the access service allowing to connect to the IPv6 Internet GeoNet Sending a location service request to discover the working NEMO geographic information of an ITS station Sending a DHAAD request message to discover the list of 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 CIMAE to the SME using Events.req(E ). (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 maximum interval 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 in the thesis and others are defined in [ISO ]. (5a) If GeoNetworking is disabled, the SME can activate GeoNetworking by setting GeoEnableStatus (N-Parameter) using MN-SET. If GeoNetworking is already running or GeoNetworking is not used, this step is skipped. N-Parameters for GeoNetworking are specified in Appendix (5b) In the case where GeoNetworking is used over the created VCIs, the VCIs is set as GeoAccessInterfaceIndex in N-Parameter for GeoNetworking using MN-SET. (6) When GeoNetworking is enabled, there are three ways to obtain the geographic information of neighbor ITS Station: beaconing, location service and packet reception. Every GeoNetworking packet has a common header that includes source nodes s geographic information. The information is notified to the SME using STAGeoNot. Note that, if GeoNetworking is not used, geographic information of neighbor ITS stations cannot be obtained 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 egress interface. Topological locator field is left as empty, because network part of link-local address (fe80 ) does not indicates the topological location. (8a) On reception of a Router Advertisement from a roadside ITS station, the system receives the topological locator information of the roadside ITS station. The information ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 61/134

63 Management Network & Transport IP (d) Path Selection (12a), (12b) (11a), (11b) Mobility protocol Locator registration Anchor Discovery (12b) PathNot.req (12a) PathMNG.req (11b) STAServNot.req (11a) STAServDiscov.req MNPP (10) ITS-S prefix discovery (10) STATopoNot.req NDP (9) PathNot.req (c) Network environment perception (9) (8a), (8b), (8c) (7) Global address configuration RA reception Link-local address configuration (8c) PathMetricNot.req (8b) STAServNot.req (8a) STATopoNot.req (7) PathNot.req (b) Interface Configuration (6) (5a), (5b) (4) GeoNetworking Packet reception Beaconing Location Service N-Parameter Acess VCI (6) STAGeoNot.req (5b) MN-SET (GeoAccessInterfaceIndex) (5a) MN-SET (GeoEnableStatus) (4) WakeUp.req, Monitor.req and etc. (a) Interface Initialization (3) (2) (1) CI Management Adaptation Entity VCI creation (TX-VCI / RX-VCI ) Interface Prioritization Interface Registration (3) Events.req(E ) (2) PrioReg.req (1) RegReq.req (0) Interface Power on Figure 5.2: Procedure of Path Management is sent to the SME using STATopoNot. Note that the system may receive geographic information of the station at the same time, when the Router Advertisement is encapsulated into GeoNetworking packet. See step (6) for this case. (8b) At the same time on the reception of the Router Advertisement, the system also detects that the neighbor ITS station provides a access service. The service capability of the ITS station is notified to the SME using STAServNot. (8c) The Router Advertisement may contain the MTU size of the access network as a Router Advertisement 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 a Router Advertisement. The SME notifies the acquisition of Global Network reachability from the egress interface with the topological locator which is the 64 bits network part of the acquired global address using PathNot. (10) Eventually, an IPv6 Internal Network Prefix Discovery (INPD) advertisement is received. From the message, the IPv6 obtains a new CoA (i.e. topological locator) and ITS station internal IPv6 network prefix of the neighbor ITS station (i.e. the neighbor ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 62/134

64 ITS station ID). The information of the neighbor ITS station is notified to the SME using STATopoNot. (11a) Once a global address is configured on an egress interface, it has to be registered to an anchor to support mobility. When there is no available anchor recorded in the ITS station information table, the SME can request service discovery of anchor service to the mobility management module using STAServDiscov. (11b) As a result of anchor service discovery (In NEMO case, DHAAD is the service discovery), the mobility management module obtains a list of anchors. The anchor list is sent to the SME using STAServNot. (12a) The SME requests IP to registers the topological locator with an anchor based on the path selection decision using PathMNG. The CI selection, address selection, access router 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. From the 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 the cycle 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 components are able to work on class of packets (flows) rather than globally. The base of the system is the IPv6 Traffic Identifier module whose role is to classify IPv6 packets according to their networking parameters (source and destination ITS station Nodes, application, type of service,...). Modules may use this classification among the network entity (IPv6 Forwarding module, 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 classification 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 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 Feedback and update The SME has to ajusts its policies to the actual network traffic. It is even more true for making cohabit flows that comes from CALM-aware and legacy applications. Statistics about each flow, either registered or not, permits the SME to make new policies that change the path of some flows to optimize network resources without breaking application requirements. The ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 63/134

65 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 energy consumption. 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 a FlowFeedback.request. (14) Upon reception of this MN-Command, the network entity has to transfer all flow statistics to the SME using the FlowStatistics request. (15) Once the whole table has been sent, the network entity confirms completion by confirming the initial command. The FlowFeedback.confirm message is sent to the SME to conclude communication. (16) The SME computes new decisions for adjusting network resources usages. It sends its actual decision on existing or new flows. It provides it by sending FlowPolicy messages. (17) The SME also sends FlowClassificationRule messages for newly defined FlowID. These messages reuse data contained in FlowStatistics messages. Peculiarly, the protocolspecific 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- ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 64/134

66 Management Network & Transport IP (f) Flow Selection (17) (16) Policy enforcement Traffic enforcement Flow enforcement (17) FlowClassificationRule.req (16) FlowPolicy.req (e) Feedback gathering (15) (14) (13) Flow Statistics (15) FlowFeedback.cfm (14) FlowStatistic.req (13) FlowFeedback.req 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 previously shown. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 65/134

67 CHAPTER 6 Module IPv6 traffic classifier 6.1 Overview In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to allow an ITS station to map incoming IPv6 traffic to a FlowID. This is ensured by the IPv6 traffic classifier module within the IPv6 protocol block. The IPv6 traffic classifier module is in charge of mapping incoming IPv6 packet to a FlowID identifying a sequence of packets of a similar pattern, e.g. all traffic originated from a given source, or all traffic intended to a given destination port, or a particular connection between two nodes, or all traffic corresponding to a given priority, etc. This classification is made based on Flow classification rules provided by the SME to the IPv6 network block through the MN-SAP. These rules are translated by the IPv6 Adaptation Agent module to parameters meaningful within the IPv6 networking protocol block. The IPv6 Traffic Identifier module tries to match each incoming IPv6 packet against "Flow classification rules". It maps each IPv6 packet to a FlowID or doesn t classifies it if no rule matches. 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 IPv6 packet, the IPv6 Traffic Identifier module operates first so as other module be able to use its classification. The classification of the IPv6 packet sticks to the packet when it evolves in the IPv6 networking stack. Each IPv6 networking module that uses per-flow rules selects the appropriate rule according 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 if existing rules does not succeed to apply, the module uses its default rules. The null FlowID is reserved for default rules. 66

68 6.3 IPv6 packets classification D2.2: Preliminary System Specification The IPv6 Traffic Identifier module classifies IPv6 packets according to informations provided in MN-Command.FlowClassificationRule. Protocol-specific information (ports, message 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 data is all data from the IPv6 header (IPv6 source, IPv6 destination, IPv6 flow label, IPv6 next header,...) 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 protocolspecific information field, it is considered as a wildcard parameter. For IPv6 addresses, a prefix 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 needs to have some statistics about how its decisions are applied. Moreover, it has to know what is the effective amount of traffic generated by each flow, either it is declared or not. The purpose of the MN-Command.FlowFeedback and MN-Request.FlowStatistics messages is to provide to the management entity the most accurate picture of the network. Whenever the IPv6 Traffic Identifier module receives a MN-Command.FlowFeedback message, it has to retrieve statistics and provide it to the management entity. The IPv6 Traffic Identifier module sends statistics using the MN-Request.FlowStatistics message. Feedback is returned by the IPv6 Traffic Identifier module in a per-connection basis. The meaning of a connection depends on its transport protocol. For connection-based protocols, connections are considered as defined by the protocol specification. For datagram-based protocols based on source and destination ports, connections are identified using a 4-tuple (source address, destination address, source port, destination port). For datagram-based protocols based on messages, connections are identified using a 3-tuple (source address, destination address, 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) to which the last packet of this connection was routed. Additionnally, it reports the number of packets per seconds and the datarate of this connection. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 67/134

69 6.5 Policy Exchange D2.2: Preliminary System Specification The Policy exchange mechanism exchanges Flow Classification rules and Flow Policies between several ITS Station nodes. Whenever two ITS Station nodes has several possible paths, a symmetric enforcement is needed on both sides of a L3link. This enforcement aims to avoid asymmetric routing situations. Such situations may lead application requirements to 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 Station node. 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 traffic rather 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 message is sent. If several pathids match the same ITS Station Node, policies may be merged in 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 way as Flow policies transmitted through the MN-SAP. In case of contradicting policies, local policies shall be preferred. When receiving policies, they shall be translated into Flow policies and reported to the management through the MN-SAP. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 68/134

70 CHAPTER 7 Module IPv6 forwarding 7.1 Overview In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to allow IPv6 packet forwarding. This is ensured by the IPv6 forwarding module within the IPv6 protocol block. The IPv6 forwarding module comprises basic IPv6 features (Neighbor Discovery, Stateless Address Auto-Configuration, etc) to acquire necessary IP parameters (IPv6 addressing) and IP next hop determination (IPv6 forwarding). It enables IPv6 to run over different lower layer technologies. It allows IPv6 packets to be sent to the next 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 IPv6 address belongs to the ITS station itself; to the relevant IPv6 Internal Station Interface module if the next hop to the destination IPv6 address doesn t belong to the ITS station itself; to the relevant IPv6 protocol block module if the packet contains no payload (IPv6 layer signaling). As a result of the notification to the ITS station management entity (SME) of a change in 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 source or destination address in the packet belongs to the ITS-S IPv6 node. According to the ITS station design (ISO Figure 14), traditional OSI network and transport layers are merged into a single layer. No transport layer function specific to CALM are needed. Should there be any, their specification is out of scope of this International Standard. However, in principle, the packets should be transmitted to some transport layer function before they are transmitted trough the NF interface. 69

71 7.2 Flow policies D2.2: Preliminary System Specification The SME provides routing policies on a per-flow basis. Flows are classified by the IPv6 Traffic Identifier module, this classification is used by the IPv6 Forwarding module to apply the appropriate routing policy Management Flow policies are managed (e.g. added, modified, deleted) by the MN-Command.FlowPolicy message. They contain pairs of (FlowID, PathID) that form a unique key. The FlowPolicy.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 are flushed by the IPv6 Forwarding Agent. Note: If the IPv6 Traffic Identifier module is not present on a node, only flow policies that contain a null FlowPolicy.FlowID are considered by the IPv6 Forwarding module. Other flow policies are ignored 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 determine the PathID. If the packet is classified: Only consider flow policies whose FlowPolicy.FlowID match the classification of the packet 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 FlowPolicy.priority Use the FlowPolicy.PathID of the selected flow policy to route the packet, if it is a null PathID, drop the packet If the packet is unclassified (default settings), use the same algorithm with the following changes: Try to match flow policies whose FlowPolicy.FlowID is null. If, finally, no flow policies match, use any available PathID. If several Flow policies have the same priority, the IPv6 Forwarding module arbitrarily chooses one of them. In this case, the IPv6 Forwarding module has to ensure not to route a single connection alternatively to several PathID. The meaning of a connection is described in the IPv6 Traffic identifier module. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 70/134

72 7.3 Required actions D2.2: Preliminary System Specification 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 IPv6 neighbors in order to determine the next IPv6 hop towards a destination reachable through an IPv6 interface to perform the forwarding function. Whenever the IPv6 forwarding module receives an IPv6 packet, it shall perform IP next hop determination and IPv6 address resolution and forward the packet to the appropriate interface (or the layer above if intended for itself) as specified in its forwarding table. The forwarding table shall be updated by the SME (ISO figure 13) based on the availability of communication interfaces and needs of the applications: Default settings of the forwarding table shall be requested from the SME through the MN-SAP using N-COMMAND.request instructions as specified in ISO Whenever the IPv6 forwarding module receives N-COMMAND.request instructions from the SME through the MN-SAP, it shall modify the forwarding table as specified in ISO ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 71/134

73 CHAPTER 8 Module IPv6 mobility support In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to allow an ITS station to maintain continuous IPv6 connectivity while changing its point of attachment to the network. This is ensured by the IPv6 mobility support module within the IPv6 protocol block. The IPv6 mobility support module comprises mechanisms for maintaining IPv6 global addressing, Internet reachability, session connectivity and media-independent handovers (handover between different access technologies) for in-vehicle networks. 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 Internet connectivity between all the nodes in the vehicle and the infrastructure (network mobility support). This is performed without breaking the flows under transmission, and transparently to the nodes located behind the MR (MNNs) and the communication peers (CNs). This is handled by mobility management functions in the MR and a server known as the HA ( Home Agent ) 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) allocated to the MR is kept irrespective of the topological location of the MR while a binding between the MNP and the newly acquired temporary Care-of Address (CoA) configured on the external IPv6 egress connecting the MR to the Internet is recorded at the HA. This registration is performed by the MR at each subsequent point of attachment to an AR. In order 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 long as the address is not deprecated. The HA is now able to redirect all packets to the current location of the vehicle. MNNs attached to the MR do not need to configure a new IPv6 address nor do they need to perform any mobility support function to benefit from the Internet connectivity provided by the MR. This mobility support mechanism provided by NEMO 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 interface pointing to a physical egress interface ( external IPv6 interface ) where packets would be 72

74 encapsulated. Such an IPv6 virtual interface would then be treated by the routing module as the physical external IPv6 interface. The same rules would thus be applied to the selection of the MR-HA tunnel (see the IPv6 forwarding module in 7. The earlier Mobile IPv6 mobility support specification [rfc3775] provides Internet connectivity to a single moving IPv6 host only (IPv6 host mobility support). Mobile IPv6 is therefore inappropriate for the most advanced ITS use cases which usually consider more than one in-vehicle embedded CPU. Network mobility support using RFC 3963 also supports situations where there would be only a single IPv6 node deployed in the vehicle. Indeed, the ability to support an entire network of n nodes includes the ability so support a network of 1 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 the design goals behind NEMO Basic Support in [rfc4886]. These documents are normative documents 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] and allows 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 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 73/134

75 notify the IPv6 forwarding module with new forwarding table entries. See the description of the IPv6 forwarding module. Different approaches have been proposed at the IETF in the former MEXT Working Group for the MR and the HA to synchronize their decisions in choosing the appropriate medium [rfc6088] and [rfc6089]. One such approach is to exchange rules (routing policies) using NEMO signaling messages; another is more generic and uses standard transport layer protocols. The rules for performing handovers and medium switching are configurable by stakeholders, e.g. users, device vendors, service providers, OEMs, car manufacturers. These rules are competitive factors among stakeholders, so the definitions of these rules are outside the 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 8.3 Required actions The mobility management module shall implement mobility support functions for Internet reachability 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 and the ITS-S IPv6 home agent for every global IPv6 address available on any external IPv6 interface. The maintenance of multiple tunnels simultaneously available between the ITS-S IPv6 mobile router and the ITS-S IPv6 home agent (HA) shall be achieved in accordance to RFC 5648 Multiple Care-of Addresses Registration (MCoA). ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 74/134

76 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 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 shall be achieved by an exchange between the ITS-S IPv6 mobile router and ITS-S IPv6 home agent of the rules notified by the ITS station management entity to the IPv6 forwarding module. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 75/134

77 CHAPTER 9 Module IPv6 ad-hoc networking In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to allow ad-hoc IPv6 communications between nearby ITS stations. This is ensured by the IPv6 ad-hoc networking module within the IPv6 protocol block. The IPv6 ad-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 other protocols, there doesn t exist such a standard specified by the IETF, so a new protocol is designed on purpose. 9.1 IPv6 Internal Network Prefix Discovery (INPD) INPD: Motivations As specified in [ISO-21210], Internet connectivity and session continuity for ITS stations changing 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 home agent (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 station communicates 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 hop away. It is even more inefficient for communications between two neighbor vehicle ITS stations which are registered with distinct HA (e.g. in the situation where the two cars 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 the same wireless link if the same media is used to access the Internet. In other words packet transmission performance is inefficient in 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 is needed to allow direct routing between two adjacent ITS stations in addition to maintaining Internet connectivity and reachability. In order to skip the HA and transmit packets over an optimal path, extensions to NBS! 76

78 (NBS!) known as Routing Optimization have been proposed, and implemented, bearing very efficient performance results. However, no solution has been standardized yet at the IETF though this was undergoing in the former MeXT Working Group (see the Routing Optimization Problem Statement [rfc4888] and the Routing Optimization [rfc4889] taxonomy RFCs). The approach adopted for direct routing between adjacent ITS stations is to announce the internal network prefix of vehicle and roadside ITS stations (IINP) to adjacent ITS stations and let them update routing tables accordingly. In addition, the ability to route directly to nodes attached to neighbor MRs and ARs must be combined with the ability for the MR to route packets to the HA i.e. backward compatibility with NBS! (NBS!) must be maintained. Without this specific mechanism, IPv6 routers on the IPv6 link would only know their respective link-local address or CoA, but not their associated IPv6 prefixes. It would thus not be possible for a node attached to an ITS station (MR or AR) to communicate with a node attached to another ITS station without transiting through the HA. In other words, without INPD, a router wouldn t be able to send packets to the IPv6 nodes attached to neighbor routers one IP hop away unless a NEMO tunnel is available, in which case all packets sent from the in-vehicle network would be routed via the HA. Accordingly, INPD improves routing performance by allowing direct communication between any two nodes attached to distinct ITS stations. IPv6 Internal Network Prefix Discovery (INPD) has originally been defined by the GeoNet project and was then known as Mobile Network Prefix Provisioning (MNPP) 1. MNPP was designed to announce only a vehicle ITS station s internal network prefix, known as the mobile network prefix (MNP) in the context of NBS! (NBS!). MNPP has thus been extended and renamed to INPD in order to remove its naming dependency with the NEMO terminology INPD: Description The INPD protocol enables direct routing between adjacent ITS stations neighbor ITS station routers (MRs and ARs). The procedure to discover adjacent ITS station s internal network prefixes is defined as IPv6 Internal Network Prefix Discovery (INPD). It allows ITS stations to advertise the IPv6 prefix of the ITS station s internal network to 1-IP-hop away neighbor routers. INPD transmits solicitation and advertisement messages between routers located on the 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 route to 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 s internal network prefix whereas the internal network prefix solicitation (INPS) messages are used to request INPA messages quickly. INPA messages contain at least the internal network prefix and the preferred lifetime and are sent onto the ITS station router s external IPv6 interface. One-hop away ITS station routers receive the INPA message and learn from these messages the link-local address of the sending ITS station router. Upon reception of the INPA messages, the receivers (neighbor routers) update their routing tables so that packets destined to the internal network prefix are directly routed to the link-local address. This direct routing remains until the preferred lifetime for the internal network prefix has expired, but this lifetime can be adjusted according to the receiver s local policy. 1 see GeoNet D2.2 [GeoNet-D2.2] Section for a more detailed description ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 77/134

79 Figure 9.1: Message Flow Example in INPD Proactive Mode INPD: Interaction with other modules The IPv6 Internal Network Prefix Discovery (INPD) protocol interacts with the following IPv6 modules: IPv6 Adaptation Agent Module: The interaction with the IPv6 adaptation agent module is required to interpret MN-COMMAND and MN-REQUEST transmitted between the IPv6 protocol block of the ITS station networking & transport layer (SNT) and the ITS station management entity (SME) and related to INPD operations. IPv6 Forwarding Module: The interaction with the IPv6 Forwarding module is required to update routing information associated with 1-IP-hop away neighbor routers. It occurs when the IPv6 INPD module successfully obtains 1-IP-hop away neighbor router s link-local address, internal network prefix, and preferred lifetime. IPv6 Security Module: The interaction with the IPv6 Security module is required to secure the process of INPD. External IPv6 Interface Module: The interaction with the External IPv6 Interface module is required to send/receive INPA messages from 1-IP-hop away neighbor routers INPD: Message flows INPD has two mode of operation, proactive and reactive: Proactive method: The ITS station router (MR or AR) periodically sends the unsolicited INPA messages containing the internal network prefix being used in its internal network. Upon reception of the INPA message, adjacent ITS stations (i.e., 1-IP-hop away neighbor routers) obtain the internal network prefix of the sender. It is similar to the case of sending unsolicited router advertisement messages defined in Neighbor Discovery Protocol. Reactive method: The ITS station router (MR or AR) upon reception of the INPS message immediately sends the solicited INPA message containing the internal network prefix being used in its internal network. The INPS message should be used to prompt adjacent ITS stations (i.e., 1-IP-hop away neighbor routers) to generate the INPA message quickly. It is similar to the case of requesting solicited router advertisement message in Neighbor Discovery Protocol. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 78/134

80 INPD: Proactive mode message flows MR multicast its INPA messages periodically. For such a unsolicited INPA message, the source address must be set to the MR s link-local address and the destination address must be set to the all-nodes multicast address (FF02::1). The INPA message sent from the MR has 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, source link-layer address (SLLA), internal network prefix (INP), internal network prefix s preferred lifetime (PLT), and internal network prefix s MTU. Note that the internal network prefix and associated preferred lifetime must be presented in the INPA message. Neighbor nodes receive the INPA message sent from the MR. They then update their routing table information based on the information contained in the INPA message. Note that the source link-layer address can be obtained from the INPA message s source address field or from the source link-layer address option field. The message flow of the proactive mode is presented in Figure 9.1. INPA messages are sent by MR 1 and received by MR 2, AR 3. As shown in Figure 9.1, if host 2 attached to the MR 2 sends data packets destined to host 1, those packets are directly sent to MR 1 from MR 2, and not sent to MR 1 s HA. The following example shows the conceptual unsolicited INPA message s sent from MR 1 : /* 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 ( E-A9) - Internal network prefix (INP) with assiciated preferred lifetime (PLT) INPD: Reactive mode message flows There are two situations within the reactive mode to quickly obtain neighbor s internal network prefixes: the INPS message may be multicast to all neighbor nodes, or sent uniquely to a given neighbor node. The message flow of the reactive mode is presented in Figures 9.2 and 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 the destination address is set to the all-router multicast address (FF02::2). The ICMPv6 type field 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 INPA message sent directly to the requester. In other words, the solicited INPA message is sent in a unicast manner in response to the INPS message. In the other situation where the INPS message is sent to a given node, the destination address of the INPS message is set to that particular node, which respond to the sender with an INPA message as explained for the first case. Figure 9.2 illustrates the case where MR 2 sends its INPS message to all neighbor nodes. The INPS message is received by MR 1 and AR 3. The source address of the solicited INPA message sent from MR 1 is set to MR 1 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 ( E-A1) ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 79/134

81 Figure 9.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 network prefixes. Figure 9.3: Message Flow Example in the INPD Reactive Mode: A node sends its INPS message 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 ( E-A9) - Internal network prefix (INP) with associated preferred lifetime (PLT) Figure 9.3 illustrates the case where MR 2 sends its INPS message to a specific node i.e. MR 1. The destination address for the INPS message is the specific node s address, i.e., MR 1 s address (FE80::260:97FF:FE02:6EA9). When MR 1 receives the INPS message, it immediately responds with an INPA message sent back to MR 2. The following is the conceptual 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 ( E-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 ( E-A9) - Internal network prefix (INP) with associated preferred lifetime (PLT) ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 80/134

82 CHAPTER 10 Module IPv6 over GeoNetworking 10.1 IPv6 over GeoNetworking: description IPv6 GeoNetworking is the combination of IPv6 networking capabilities together with GeoNetworking capabilities. Typically, routers (MRs and ARs) with GeoNetworking capabilities are able to transmit IPv6 packets over a multi-hop link made of forwarding ITS stations (vehicles, and possibly roadside). Associated with IPv6 multicast capabilities, routers with IPv6 GeoNetworking capabilities are able to distribute IPv6 packets to a set of nodes located in a given geographical area, either around the sending node or at a remote geographical location. The mechanisms combining IPv6 and GeoNetworking have originally been defined by the GeoNet European Project, taking as an input the GeoNetworking capabilities defined by the Car2Car Communication Consortium and IPv6 networking defined in ISO The architecture [GeoNet-D1.2] and the specification [GeoNet-D2.2] are publicly available and can be found on the GeoNet European Project web site [url-geonet]. At a later stage, a subset of the GeoNet work has been standardized by ETSI TC ITS. Once IPv6 is combined with GeoNetworking, the network layer is composed of two sublayers which are pilled up. IPv6 being above GeoNetworking. IPv6 performs all the conventional IPv6 layer functions plus IPv6 mobility management functions (vertical handovers and multihoming) while GeoNetworking is in charge of the routing functions based on geographic positions of the vehicles). GeoNetworking indeed appears as a link layer from the point of view 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 and transmitted 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.2 Routers with GeoNetworking capabilities are forming a particular case of vehicular ad-hoc network (VANET). MRs and ARs combining both IPv6 and GeoNetworking capabilities and located in a bounded geographical area form an IPv6 sub-network and are reachable on a unique virtual IPv6 link, which is referred to as the IPv6 C2CNet link. Taking a look at Figure XX 10 XX, MR3 and AR2 are on the same IPv6 link although there is an intermediate router (MR4) in between. The actual topology of the network is thus hidden to the MRs at the 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 the C2CNet egress interface. All routers on this IPv6 C2CNet link are configuring their IPv6 81

83 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 conventional way, 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. The C2CNet layer determines the C2CNet ID (aka of MAC address) of the next IP hop and transmit 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 ] but is currently incomplete GeoNetworking Layer GeoNetworking is the ITS station networking & transport protocol block performing geographic addressing and routing functions. It corresponds to the GeoRouting component of the ITS station. GeoNetworking is indeed a layer, which plays a crucial role as it is in charge of the geographic addressing and forwarding functions, i.e. forwarding a packet destination nodes located in a given geographic area. Details of the GeoNetworking layer can be found in the publicly available GeoNet deliverable [GeoNet-D2.2]. Most of the GeoNetworking capabilities specified by the GeoNet project have since been taken over by ETSI TC ITS and are specified as [ETSI-TS , ETSI-TS ]. In the GeoNet project, the GeoNetworking layer was originally referred 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 capabilities, this module is responsible for calculating the position information to be used for GeoNetworking. This modules is also responsible for geographical relevance check. GeoRouting: implemented in all MRs and ARs with GeoNetworking capabilities, this module is in charge of forwarding packets from a source to a destination based on geographical information such as position or velocity. It is composed of following submodules: GeoUnicast, GeoBroadcast, GeoAnycast, TopoBroadcast and Store and forward. Store and forward is a sub-module that stores the packet locally for a defined period of time when the forwarding of the packet is not possible. The GeoRouting function is based on the GPSR (Greedy Perimeter Stateless Routing for Wireless Networks) routing algorithm. Location management: implemented in all MRs and ARs with GeoNetworking capabilities, this module manages location information among communication peers (position calculation and maintenance of the neighboring nodes position). It is composed of the following sub-modules: Beaconing: This sub-module keeps transmitting a periodic packet to inform its neighbors about its presence. This packet is called network beacon, and contains only the common header (as defined by C2C-CC) which contains a position vector to inform about own position information. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 82/134

84 Location table: This sub-module is used to record locally the location information of neighbors and other potential destination nodes. Location service: This sub-module resolves the geographic location of a communication peer when location table has no valid entry for it Required actions The IPv6 over GeoNetworking module behaves as a IPv6 External Interface module. It allows IPv6 packets to be encapsulated and sent to the next IP hop through the IPv6 GeoNetworking link. It thus performs IP address resolution over the IPv6 GeoNetworking link in order to transmit packet to nearby MRs and ARs in the vicinity and transmits the IPv6 packets between the IPv6 layer and the GeoNetworking layer in the appropriate format. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 83/134

85 CHAPTER 11 Module IPv6 security 11.1 Overview In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to secure IPv6 communications. This is ensured by the IPv6 security module within the IPv6 protocol block. The IPv6 security module performs the functions required at the IPv6 layer to secure both IPv6 signaling and IPv6 payload. It comprises security protocols such as SeND, IPsec, Shared-key-based authentication, etc. offering the service mechanisms defined in [X.800, Lee2011b]. It interacts with the ITS station security entity (SSE), with the ITS station management entity (SME) and other IPv6 modules. The IPv6 security module is defined to: implement security mechanisms necessary for achieving required security services through security 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 such operations are requested from the IPv6 security module [Lee2011b, Lee2012a], for instance when the IPv6 security module requests an arbitrary bit string for location privacy. The interactions between the SSE and the IPv6 security module is performed via the SN-SAP, in a security mechanism/protocol agnostic way so that the behavior of the ITS station security entity 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 for security services to be applied on a given flow are provided by the ITS station management entity (SME) to the IPv6 networking protocol block, so that the IPv6 traffic classifier module is able to determine on which IPv6 interface packets should be provided. The IPv6 security module 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

86 module of the IPv6 networking protocol block to the SME, informing the required security services for a given flow from the SME to the IPv6 security module of the IPv6 networking protocol block) between the SME and the IPv6 networking protocol block is performed via the MN-SAP. The text in this chapter is being contributed to the new ISO work item CALM: IPv6 Networking 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 resources of the system or of other systems. Security services are implemented via security mechanisms/protocols. Security services and mechanisms are defined by ITU-T [X.800] and described in Sections and ITU s definition of security services and mechanisms Security services The following security services are defined as [X.800]: The peer entity authentication service defined in X.800 provides the corroboration that a peer entity in an association is the one claimed; The data origin authentication service defined in X.800 provides the corroboration that the source of the data received is as claimed; The access control service defined in X.800 provides protection against unauthorized use of resources; The connection confidentiality service defined in X.800 provides for the confidentiality of all user data on a connection; The connectionless confidentiality service defined in X.800 provides for the confidentiality of all user data in a single connectionless data unit; The traffic flow confidentiality service defined in X.800 provides for the protection of the information which may be derived by observing traffic flow; The connection integrity without recovery service defined in X.800 provides for the integrity of all user data on a connection. It also provides the detection ability for any modification, insertion, deletion, or replay of user data within an entire data unit with no recovery attempted; The connectionless integrity service defined in X.800 provides for the integrity of a single connectionless data unit. It also may provide the detection ability for any modification of 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.800 but particularly required for mobile ITS stations (e.g., vehicle ITS station), provides protections against observers examining user data to extract location information Security mechanisms The following security mechanisms are defined as [X.800]: ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 85/134

87 Cryptographically derived or protected authentication exchange mechanism: It can be used to provide the peer entity authentication service. Signature mechanism: It consists of message signing and message verifying. The peer entity authentication service and data origin authentication service can be achieved by the digital signature mechanism. Encipherment mechanism: It provides confidentiality of either data or traffic flow. It can be used as a part in or complement a number of other security mechanisms. The data origin authentication service, connection confidentiality service, and connectionless confidentiality service can be achieved by the encipherment mechanism. Access control mechanism: It is used to provide the access control service, i.e., to provide protection against unauthorized use of resources/services. The provision of access control is a nontrivial security service which involves the application of different security mechanisms. On the one hand, authentication mechanims are needed to ensure the 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 access rights. Routing control mechanism: It provides a dynamic or pre-defined routing to use only physically secure sub-networks, relays, or links. The connection confidentiality service and connectionless confidentiality service can be achieved by the routing control mechanism. 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 without recovery service and connectionless integrity service, sometimes in conjunction with an encipherment mechanism. Pseudonym configuration mechanism: It can be used to preserve location privacy. It utilizes a set of pseudonyms in IPv6 address and communication. The pseudonym configuration mechanism is not the security mechanism defined in [X.800] and is only required to the IPv6 security module deployed in vehicular and personal ITS subsystems. The pseudonym configuration mechanism utilizes a set of pseudonyms that are temporary identifiers (generated from arbitrary bit string) for IPv6 communications 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 : Authentication service: The IPv6 security module shall assure that IPv6 communications between ITS stations are authentic in terms of peer entity authentication and data origin authentication services. The peer entity authentication service provides the corroboration that a peer entity in an association is the one claimed, whereas the data origin authentication service provides the corroboration that the source of the data received is as claimed. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 86/134

88 Access control service: The IPv6 security module shall have the ability to limit and control any access via IPv6 communications. Confidentiality service: The IPv6 security module shall provide the protection of IPv6 communications from unauthorized disclosure in terms of connection confidentiality, connectionless confidentiality, and traffic flow confidentiality services. The connection confidentiality service provides for the confidentiality of all user data on a connection, whereas the connectionless confidentiality service provides for the confidentiality of all user data in a single connectionless data unit. The traffic flow confidentiality service provides for the protection of the information which may be derived by observing traffic flow. Integrity service: The IPv6 security module shall provide the protection of IPv6 communications from unauthorized modification in terms of connection integrity without recovery and connectionless integrity services. The connection integrity without recovery service provides for the integrity of all user data on a connection. It also provides the detection ability for any modification, insertion, deletion, or replay of user data within an entire data unit (with no recovery attempted). The connectionless integrity service provides for the integrity of a single connectionless data unit. It also may provide the detection ability for any modification of user data and the limited detection ability for replay of user data. Location privacy support service: The IPv6 security module shall provide the necessary functionality that allows vehicular and personal ITS-S subsystems to preserve location privacy from observers examining the header of IPv6 packets. The location privacy support service is not the security service defined in [X.800]. This security service is specially required for vehicular and personal ITS-S subsystems that have mobility at the IPv6 layer. Figure 11.1 shows the mapping between security services and security mechanisms as they can be provided by the IPv6 layer. The security services are provided in different combinations according to the type of ITS station IPv6 node, as illustrated on Figure Similarly, the security mechanisms are provided in different combinations according to the type of ITS station IPv6 node, as illustrated on Figure IPv6 security protocols implementing security services In order for the IPv6 layer to provide the above security services, a number of security protocols must be implemented. These are: SeND (SEcure Neighbor Discovery) as specified in [rfc3971] for securing the neighbor discovery protocol (NDP) [rfc4861] which operates between vehicle and roadside ITS stations. IPsec, as specified in [rfc4301] and other RFCs for securing all types of IPv6 traffic including NEMO signaling [rfc3776]; Shared-key-based authentication as specified in [rfc4285] Authentication Protocol for Mobile IPv6 for securing location update signaling. A pseudonym configuration mechanism for providing location privacy from IPv6 addresses [rfc4941]; ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 87/134

89 Figure 11.1: Security services achieved by security mechanisms at the IPv6 layer ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 88/134

90 Figure 11.2: Mapping of security services to types of IPv6 node Figure 11.3: Mapping of security mechanisms to types of Pv6 node ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 89/134

91 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 address for which the rightmost 64 bits of the IPv6 address, i.e., interface identifier, is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters [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 of ITS station IPv6 node, as illustrated on Figure The security protocol are required to protect IPv6 packets passing to both the external IPv6 interface(s) and the internal IPv6 interface(s) (interface to the ITS station IPv6 LAN), as illustrated on Figure Location update signaling, i.e., NEMO s binding update (BU) and binding acknowledgement (BA) messages is protected either by IPsec or the shared-key-based authentication. The shared-key-based authentication, which produces less signaling overhead than IPsec is only recommended in certain cases, when, e.g., no location privacy is required, or access network authentication is established by other means Interaction with other modules and entities The IPv6 security module s primary role is to enforce the security services to incoming and outgoing packets/sessions. The determination of the security services to be applied on a given ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 90/134

92 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 and external) ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 91/134

93 flow comes from the SME. The execution of the security services at the IPv6 layer is done by 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 request for activating a specific security service, the IPv6 security module of the IPv6 networking protocol 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 IPv6 security 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 security mechanism(s)/protocol(s) is not currently used to provide other security service(s) Interaction with ITS station management entity The ITS station management entity (SME) requests the IPv6 networking protocol block to activates/deactivates security services and to update/lock pseudonyms. On the other direction, the IPv6 networking protocol block provides the ITS station management entity (SME) with a list of available security services per routing interface. This interaction is performed 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 made through the IPv6 adaptation agent module which interprets the MN-REQUEST and MN- COMMAND and interact with the IPv6 security module located at the IPv6 networking protocol block Interaction with ITS station security entity The IPv6 security module communicates with the ITS station security entity (SSE) through the SN-SAP using the SN-COMMAND and SN-REQUEST services. Details of the SN-SAP are provided in Section 15. The interactions with the SSE are mostly related to atomic security operations. When atomic 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 sharedkey-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 atomic security operations (e.g. keyed hash value) is returned back to the IPv6 Security module via the SN-SAP. Another example is a pseudonym change at the IPv6 layer. Suppose that a vehicle 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 the SSE via the SN-SAP Interaction with other IPv6 modules Within the IPv6 networking protocol block, the IPv6 security module interacts with the following modules: IPv6 adaptation agent module A list of available security services per routing interface is provided from the IPv6 security module to the IPv6 adaptation agent module when bootstrapping the IPv6 security module for the given routing interface is performed. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 92/134

94 IPv6 mobility support module For moving ITS stations (vehicle ITS station, personal ITS station), an interaction with the IPv6 mobility support module is required to obtain mobility status. IPv6 adhoc networking module The interaction with the Internal Network Prefix Discovery protocol is required to obtain neighbor status. IPv6 multicasting module The interaction with the IPv6 multicasting module is required to obtain the multicast status. IPv6 internal interface module The security check for incoming packets/sessions from the IPv6 internal interface module is performed by the IPv6 security module. Only valid packets/sessions are passed to other modules for further processing within the IPv6 networking protocol block. After security protection to outgoing packets/sessions, the secured packets/sessions are sent to the Internal IPv6 Interface module. IPv6 external interface module The security check for incoming packets/sessions from 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 protocol block for further processing. After security protection to outgoing packets/sessions, the secured packets/sessions are sent to the External IPv6 Interface module Pseudonym configuration at the IPv6 layer Location privacy may be required, particularly for some users of mobile ITS stations deployed in vehicles or personal devices. This section provides a description of a pseudonym configuration mechanism utilizing a set of pseudonyms at the IPv6 layer Pseudonym For location privacy, temporary identifiers, i.e., pseudonyms, are used with an appropriate changing scheme, e.g., a vehicle ITS station uses its current pseudonym P 1 in a short period t P1 and changes P 1 to a new one P 2 for the next short period t P2. By using these pseudonyms, attackers are not able (or at least not easily) to link different pseudonyms in order to identify the vehicle ITS station emitting messages with these pseudonyms. A pseudonym is interpreted in different forms depending on the layer/protocol. Here we assume that the pseudonym is an arbitrary bit string. For the access layer, the 48 bits of MAC address are replaced by the pseudonym. For the GeoNetworking layer, the rightmost 48 bits of the GeoNetworking address, which correspond to the MAC address, are also replaced by the 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 generated based on the pseudonym. It is worth noting that the pseudonym is synchronously changed across the entire ITS station stack. For instance, when a current pseudonym is changed to a new one, the whole MAC address is replaced by the new pseudonym, while the GeoNetworking address and the IPv6 address are changed accordingly. The IPv6 security module provides a pseudonym, which is randomly generated 48 bits, to the external IPv6 interface module that generates the 64 bits of an interface identifier based on the provided pseudonym. The external IPv6 interface module configures the 128 bits of a global IPv6 address based on the generated interface identifier. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 93/134

95 Figure 11.7: Considered network topology Pseudonym configuration Pseudonym update due to mobility The IPv6 security module receives a new pseudonym from the security entity when the ITS station mobile router changes its attachment point, i.e., network-level handover, through the SN-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 pseudonyms obtained from the security entity are used to update the mobility binding Pseudonym change due to the mobility lifetime expiration The IPv6 security module receives a new pseudonym from the security entity before the lifetime of the mobility binding is expired through the SN-COMMAND service of the SN- SAP Pseudonym change due to the pseudonym lifetime expiration The IPv6 security module receives a new pseudonym from the security entity before the lifetime of the current pseudonym is expired through the SN-COMMAND service of the SN-SAP Example of pseudonym change at the IPv6 layer An example for the pseudonym change is provided that requires the SN-SAP and MN-SAP involvement. Fig shows the considered scenario wherein a vehicle ITS station implementing IPv6 mobility, i.e., NEMO, changes its attachment point from AR-1 to AR-2. Fig shows the required procedures when the vehicle ITS station moves to the new network of AR-2. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 94/134

96 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 ITS station V moves to the new network of AR V receives a RA message containing the network prefix NP 2 for the new network of AR V is required to configure its new address (Care-of Address) CoA 2 with NP 2. However, in this step, a new pseudonym P 2 instead of its previous pseudonym P 1 or its MAC address is used to generate CoA 2 with NP 2. For this, the networking & transport layer requests P 2 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 optional and specific values for PseuReq. For instance, an internal identifier of P 1, which is being used, is carried out. As the security entity receives SN-REQUEST.request, it replies with SN-REQUEST.confirm: SN-REQUEST.confirm(CommandRef, SN-ReqConfirm, ErrStatus), where CommandRef is the same number obtained from SN-REQUEST.request, SN-ReqConfirm contains P 2 with other values, e.g., an internal identifier of P 2, and ErrStatus indicates a successful provision of P 2. Note that an error status is reported in ErrStatus, ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 95/134

97 e.g., when P 2 cannot be retrieved or cannot be provided at this request time. Then, if P 2 is successfully provisioned, the networking & transport layer reports its pseudonym change to the management entity via the MN-SAP. As P 2 is provided to the networking & transport layer, it is used to generate CoA 2 with NP 2 : CoA 2 = F U L (NP 2 EUI64(P 2 )), where is a concatenation operation, EU I64( ) is an EUI-64 function that generates the interface identifier based on P 2, and F U L ( ) is a function for the modified EUI-64 that inverts universal/local bit. For instance, suppose NP 2 and P 2 are 2002:db8:1:2::/64 and 00:1D:BA:06:36:62, respectively. Let IID P2 denotes the interface identifier generated based on P 2. Then, by EUI64(P 2 ), IID P2 is obtained as 00:1D:BA:FF:FE:06:36:62. Then, an unlinkable address, i.e., CoA 2, with its previous address, is generated as 2002:db8:1:2:021d:baff:fe06: Before the use of CoA 2 in unicast communication, the uniqueness should be checked via the duplicate address detection (DAD) procedure. Then, if CoA 2 is unique, V uses CoA 2 to inform its new location by sending a BU message to its home agent (HA). The new 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 of pseudonym. Suppose that the current pseudonym s lifetime t P2 has expired. Then, V has to reconfigure its current Care-of Address CoA 2 even if it has not moved to another network. For this, the management entity sends the networking & transport layer MN-COMMAND.request: MN-COMMAND.request(CommandRef, MN-Command), where MN-Command.No is set as 10 (PseuUpdate) and MN-Command.Value contains the internal identifier of current pseudonym, i.e., P 2. As the networking & transport layer receives this command, it requests a new pseudonym to the security entity as like step 3). After a successful provision of the new pseudonym P 3, the networking & transport layer reports its pseudonym update to the management entity by sending MN-COMMAND.confirm: MN-COMMAND.confirm(CommandRef, MN-CmdConfirm, ErrStatus), where CommandRef is the same number obtained from MN-COMMAND.request, MN-CmdConfirm contains the optional confirmation data, e.g., internal identifier of P 3, and ErrStatus indicates a successful provision of P 3 or an error reason if the error occurs. Then, similar to the previous address generation, a new Care-of Address CoA 3 is generated as: CoA 3 = F U L (NP 2 EUI64(P 3 )), where P 3 is used for generating its new interface identifier IID P3. In order to check the uniqueness of CoA 3, the DAD procedure is performed again. 7. V sends a new BU message containing CoA 3 as a source address. 8. Upon receiving the BU message, the HA updates its binding cache for V and replies with the BA message. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 96/134

98 11.7 Access Control Mechanisms for IPv6 communications As described in previous section, access control is a key security service that is applied regardless of the ITS station node type. In the following, we present a description of the different mechanisms that can be implemented at the IPv6 security module according to the particular needs that may appear in ITS environments General overview of access control Generally speaking, access control is defined as the process of limiting the access to resources in such a manner that only legitimate users can access these resources. The application of access 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 entity and 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 security policies which, taking as input the user s information previously gathered, it is determined if the user is granted or denied access to the resource. 3. Enforce the application of access rights. This final action ensures that the specific conditions that limit the user s access are applied. In the ITS-S reference architecture, access control is a security service that can be provided at different layers: access, network & transport and facilities. The higher the layer, the finergrained access control can be applied. For example, while at the access layer the access control can be applied to frames transmitted over a data link connection established between two ITS station IPv6 nodes, at the facilities layer a more sophisticated and richer access control 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 can distinguish only between network layer entities. At the time being, since we are discussing the security functionalities provided by the IPv6 security module located at the networking & transport layer, the access control is applied to limit 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 the IPv6 security module, it is worth mentioning that the access control service may be provided by a combination of access control mechanisms implemented by the different layers integrating the ITS-S architecture. For example, the application of an access control mechanism over IPv6 packets could require the invocation of a mechanism available at the facilities layer to authenticate the communicating ITS stations Access control mechanisms provided by the IPv6 security module Similarly to the access control mechanisms available at the OSI network layer, the access control mechanisms provided by the IPv6 security module can be classified in two different groups: ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 97/134

99 Non-cryptographic access control mechanisms. This group refers to mechanisms that do not rely on cryptographic operations (e.g., encipherment, signature, etc.) to limit the establishment of IPv6 communications. These mechanisms may typically take as input information from the IPv6 packet itself (origin/destination IPv6 address or port, protocol, TTL, TOS,...) to match the specific IPv6 datagrams affected by the access control mechanisms. Cryptographic access control mechanisms. This group integrates mechanisms that rely on cryptographic operations to limit the establishment of IPv6 communications. For this reason, these mechanisms will interact with the ITS station security entity through the SN-SAP to request the execution of atomic operation such as hashing, signing/verification, encryption/decrypting, arbitrary bit generation, etc. Regardless of the type, the application of an access control mechanism requires the existence of a policy that determines the effect of the access control mechanism, i.e., what kind of IPv6 communications are restricted and the type of limitation. According to the X.800 specification, a repository called security management information base (SMIB) contains the necessary 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 architecture being defined by ETSI/ISO. The most famous non-cryptographic access control mechanism is the Netfilter framework implemented by Linux kernel. Netfilter allows the implementation of firewalling solutions by intercepting and manipulating IP packets send or received through interfaces. Basically, this tool is based on a table containing a set of rules that guide the filtering or transformation of IP packets. These tables can be administered through user-space programs like ip6tables that 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 IPv6 security 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 neighbour discovery message is the owner of the claimed address. Firstly, a public-private key pair is 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 address with the cryptographic hash of the address owner s public key. Additionally, the NDP messages are signed with the corresponding private key. Thus, the SEND protocol implements an access control for IPv6 NDP packets send by a certain ITS-S IPv6 node which is based on cryptographic operations (public/private key pair generation, hashing, signature, etc.) which may be requested to the ITS station security entity through the SN-SAP. Similarly, the IPSec security framework provides [rfc4301] cryptographic access control within the IPv6 security module. For example, this security protocol is used for securing the location update signalling [rfc3776] between the mobile router and the home agent. The protection of IPv6 packets can be performed by using two different protocols: AH (Authentication Header) or ESP (Encapsulating Security Payload). While AH supports integrity and data origin authentication to IPv6 packets, ESP offers a highest security protection by enabling confidentiality of IP message contents. Before establishing an IPSec based access control, the involved ITS station IPv6 nodes are required to authenticate each other. This mutual authentication is typically performed by means of the IKEv2 protocol [rfc4306] which, in turn, relies on authentication mechanisms ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 98/134

100 such as the Extensible Authentication Protocol [rfc3748]. As result of a successful authentication, IKEv2 allows the establishment of the so-called IPSec SA, i.e., parameters such as keys or algorithms to be used by AH or ESP. It is important to note that IKEv2 is an application layer protocol managed by the ITS station security entity and not implemented by the IPv6 security module. The application of IPSec based access control to IPv6 communications is determined by the security policy database (SPD), which contains a set of rules indicating what kind of IPv6 traffic must be protected once a successful IPSec SA is established Example of network access control with EAP authentication support This section is intended to show an application example of the access control functionality provided by the IPv6 security module to implement an access control solution for restricting the access to the network resource. Fig shows the considered scenario where a vehicle ITS station changes to a new point of attachment (AR). Following the standard mobility procedures, the vehicle s MR receives a RA message from the AR containing the network prefix (NP) which is used by the MR to configure the new MR s CoA (Care-of-Address). Next, the uniqueness of this CoA is checked through the duplicate address detection (DAD) protocol. Before the use of the new configured CoA for IPv6 communications (e.g., to inform the home HA about the new vehicles s location), the MR must get authenticated against the AR to gain access to the network. In fact, this policy could be enforced by the MR by configuring the SPD in order to require the use of, for example, ESP protection for IPv6 communications between MR and AR. To establish the necessary IPSec SA, the IKEv2 protocol is executed between MR and AR where EAP is used as authentication mechanism. While the MR acts as EAP peer, the AR implements the EAP authenticator functionality. The EAP authenticator may contact the home AAA server (acting as EAP server) through the AAA infrastructure. Once the EAP authentication is successfully completed, the IKEv2 protocol negotiates the parameters of the IPSec SA (keys, algorithm to encipherment, keys, etc.). This IPSec SA is used to protect IPv6 packets transmitted between MR and AR through the ESP security protocol, thus satisfying the restriction on the AR for granting access to the network service to attached MRs. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 99/134

101 EAP server AAA (Proxy) AAA Home ITS Station Visited ITS Station Road Internal Network Internet EAP authenticator EAP peer Figure 11.9: Vehicle ITS accessing to Internet through a roadside ITS station ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 100/134

102 CHAPTER 12 Module IPv6 multicasting 12.1 Overview In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to perform IPv6 multicast operations. This is ensured by the IPv6 multicasting module within the IPv6 protocol block. The IPv6 multicasting module performs the functions required at the IPv6 layer for multicast communications, i.e. mechanisms for IPv6 multicast group advertisement, IPv6 multicast group membership and IPv6 multicast routing. The protocol used to manage multicast group membership on an IPv6 link is the Multicast Listener 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 that listen to multicast packets) and multicast routers. Multicast Listener Discovery allows nodes attached to an ITS station internal network to join the multicast group address bound to specific applications requiring the transmission of IPv6 packets to multiple destinations. The multicast sender could be located either in the ITS station internal network served by another ITS station router, in a legacy access network or in the Internet. Specific mechanisms like Proxy MLD or either multicast distribution tree are used to deliver the multicast traffic from the source to the set of destinations. This module is required for the distribution of IPv6 packets to a group of destinations located in a designated geographical area when IPv6 is combined with GeoNetworking capabilities (see Section 10). Indeed, geographical areas could possibly mapped to a multicast group once other features are added in the ITS station management entity and at the ITS station facilities. This has initially been proposed by the GeoNet European Project and is detailed in [GeoNet-D2.2] Section 11. The combination of IPv6 multicast and GeoNetworking as defined by the GeoNet project allows hosts attached to the ITS station internal network to receive multicast packets sent to all ITS stations located in a specific geographic area (e.g. hazardous event notifications). Though the addition of MLD could be considered obvious, the mapping between multicast addresses and geographical areas remains a research topic. However, a static configuration can be used instead for well-known groups until dynamic mechanisms are fully specified. IPv6 multicast over GeoNetworking is currently not yet adopted in any ISO or ETSI standard, since IPv6 GeoNetworking as defined by ETSI is only used to transmit IPv6 unicast packets over a link made of intermediate non-ip hops used as forwarders. 101

103 12.2 Required actions D2.2: Preliminary System Specification Requirements to be contributed to ISO standardization have not yet been discussed. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 102/134

104 CHAPTER 13 Module IPv4-IPv6 interoperability 13.1 Overview In this Chapter we describe the procedures within the ITS station networking & transport layer (SNT) to perform operations related to interoperability between IPv4 and IPv6. This is ensured by the IPv4-IPv6 interoperability module within the IPv6 protocol block. While all ITS sub-systems required to support IPv6 for TCP/IP-based communications, IPv6 nodes deployed in an ITS station may need to communicate with existing IPv4-only legacy ITS services 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 IPv6 connectivity, 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 the required features are not yet defined. IPv6 access over IPv4 access networks for both continuous and non-continuous Internet connectivity 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 networks. Alternatively, solutions such as Softwire [rfc5571] or OpenVPN may also be used to provide the ITS station with IPv6 connectivity using a tunnel. The tunnel is build between the ITS Station and a tunnel provider inside the network center. The tunnel is then available for the mobility mechanism to perform a handover on. Header and data compression mechanisms may be used on some tunnel solutions like Softwire in order to reduce the encapsulation overhead. Differents solutions are available in order to access IPv4-only services from the IPv6 network of an ITS Station. Solutions can be offered at the network center level or at the service level. At the network center level, NAT64 [rfc6146] is an easy to deploy solution that perform translation of IPv6 packets into IPv4 packets. This solution has no impact on the client nor the server side. But it has to be noted that NAT64 has an impact on the behavior of some protocols like SIP for example, as address translation is only done in Layer-3 header, not in application headers. At the service level, the obvious solution is to migrate the legacy service into an IPv6-ready service. But this update of the service may have an impact on the quality of the existing service (untested new hardware or software, etc.). Solution like Application Level Gateway can be considered to achieve in a side deployment of IPv6 compatibility of the service without impacting the existing service. This solution consists in 103

105 a dual-stack application-specific proxy like reverse HTTP proxy or SIP proxy which will be deployed besides the existing service. Deploying dual IPv6 and IPv4 stacks in ITS-S IPv6 LANs is not recommended as it wouldn 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 such as network mobility support and other extensions are not supported in IPv4. It has to be noted that, as the ITS-S LAN will be IPv6-only, the hosts and applications connecting to this network should be IPv6-compatible Required actions ITS-S IPv6 routers shall provide IPv4/IPv6 transition mechanisms to transmit packets over IPv4 networks between ITS-S IPv6 LANs. IPv4/IPv6 transition mechanisms shall be offered so that ITS-S IPv6 LAN nodes can communicate with legacy IPv4-only nodes. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 104/134

106 CHAPTER 14 MN-SAP: Interface between Management and Network entities In this chapter we describe the procedures required for path and flow management (path selection manager) between the SME and SNT for IPv6 networking i.e. the actions requested for the IPv6 protocol block to inform the SME about the current network conditions and for the SME to provide routing policies to the IPv6 protocol block. The interaction is performed via 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 the existing Management Information Base (MIB) of the IPv6 and TCP/UDP protocol blocks in the SNT. The two other ones (MN-REQUEST and MN-COMMAND) are needed to instruct the IPv6 protocol block to route flows to a given path and correspond to the primitives already 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-COMMAND commands do not fulfill our design requirements. We thus extend these primitives to transfer the necessary information between the SME and the IPv6, GeoNetworking and TCP/UDP protocol blocks of the SNT. Six new MN-REQUEST commands (STAGeoNot, STATopoNot, STAServNot, PathNot, and PathMetricNot, FlowStatistics) and five new MN-COMMAND commands (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 presented in Section Then, the parameters and primitives for path selection (MN-REQUEST and MN-COMMAND) are presented in Section Note that this study is based on year 2012 versions of the ISO Standards and that the standards constantly evolve. As a result, primitives and parameters of the MN-SAP may have changed at time of reading Overview The interaction between the ITS station management entity (SME) and the ITS station networking & transport layer (SNT) for IPv6 networking is illustrated on Figure From the SNT, the network status is notified to the SME so that availability of new and existing paths can be determined by the SME. From the SME, instructions are provided to the SNT where 105

107 they are interpreted by an adaptation agent that translates and passes these instructions to the appropriate module (on the figure, a set of protocols for ease of undertanding). MN-GET MN-SET Management MN-SAP Network & Transport Adaptation Entity 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] Path Selection Manager N-parameter Adaptation Agent TCP UDP NEMO IP Filter Routing NDP GeoNetworking IP Transport ITS Local Network Other Protocols GeoNetworking MN-COMMAND 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 is issued from the SNT to the SME to notify an event happened (MN-REQUEST). The other one is issued by the SME to the SNT to read the values contained in the MIB (defined as N-Parameter in ISO specifications - see Section ) updated regularly by the SNT (MN-GET). There are also two modes for the instructions, both of them are issued by the SME to the 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 the SNT (MN-SET) N-Parameter exchange MN-SET command MN-GET and MN-SET are new commands that provide means for the SME to access the 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 ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 106/134

108 MN-SET.request The primitive MN-SET.request allows the SME to set N-Parameters. The parameters of the MN-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 SNT if applicable. Name Type Description CommandRef 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 of Management Information Version 2 (SMIv2) [rfc2578] N-Param.Value Value of the N-Parameter. Table 14.1: MN-SET.request parameters MN-SET.confirm The primitive MN-SET.confirm reports the result of a previous MN-SET.request. The parameters 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 values in 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 read from write-only N-Parameter. The error codes are the same as the ones used for MI-SET in [ISO ] MN-GET command MN-GET.request The primitive MN-GET.request allows the SME to request the reporting of N-Parameter values. The parameters of the primitive MN-GET.request are as follows: MN-GET.request ( ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 107/134

109 Name Type Description CommandRef 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 SMIv2 [rfc2578] Errors.errStatus One octet integer Return error code. See details in [ISO ] 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. On receipt of the primitive MN-GET.request N-Parameters shall be reported to the SME. Name Type Description CommandRef 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 SMIv2 [rfc2578] Table 14.3: MN-GET.request parameters MN-GET.confirm The primitive MN-GET.confirm reports N-Parameter values to the SME. The parameters of the primitive MN-GET.confirm are as follows: MN-GET.confirm ( ) CommandRef, N-Param.OID, N-Param.Value Errors.errStatus This primitive is the response to MN-GET.request. In the case of Errors.errStatus = success, N-Param.Value is set to the value of the requested parameter. Possible error status includes invalid N-Parameter object identifier and attempt to write to read-only N-Parameter value. The error code are the same as the ones defined for MI-SET in [ISO ] N-Parameter for IPv6 We define N-Parameters in the ITS station networking & transport layer (SNT) as a set of virtual databases. This complies with I-Parameters defined in the access technologies layer [ISO ]. 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 Section provide means for the SME to read and write the values of N-Parameter. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 108/134

110 Name Type Description CommandRef 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 SMIv2 [rfc2578] N-Param.Value Value of the N-Parameter. Errors.errStatus One octet integer Return error code. See details in [ISO ] Table 14.4: MN-GET.confirm parameter description In IPv6, some of the necessary protocols already have a virtual database called Management Information Base (MIB) defined by IETF. Objects in the MIB are defined using a 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], the term 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 Transmission Control 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] and for NEMO [rfc5488] have been defined by the IETF, as well. No MIB is defined yet for the GeoNetworking protocol. Section presents a attempt of the definition of the necessary objects. Note that a MIB must also be defined in the SME in the ITS Station Architecture, however it won t serve the same purpose and should not duplicate the N-Parameters contained in the SNT. The N-Parameters in the SNT should indeed be considered as the parameters that define the default behavior of SNT. On the other hand, the MIB in the SME would be used to respond to the requests to read and write the parameters (i.e. to be used to respond to the SNMP request from the other node). When there are common parameters in the SME and the SNT, the value of an object of 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 is requested to read/write to such parameters, it redirects the request to the N-Parameter using MN-GET and MN-SET (defined in Section ) via the MN-SAP N-Parameters for GeoNetworking We classify the parameters into the basic setting of GeoNetworking and five main functions such as Communication Interface (CI), Location Table (LT), Beaconing, Location Service (LS) and Forwarding. Table 14.2 shows all the parameters for GeoNetworking. We keep the statistics table for GeoNetworking for future work (Such statistics for IP are defined in MIB for IP as IP statistics table in [rfc4293]). All the parameters should be accessible from the management entity by MN GET and MN SET with read and write permission. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 109/134

111 Others Forwarding LS Beacon LT CI Basic Parameter GeoCapability GeoN odeid GeoIpInterf aceindex GeoAccess Interf aceindex LocationT ablelif et ime LocationT ablem axn ode LocationT ableentry BeaconInterval BeaconHopLimit LocationServiceT ype LocationService HopLimit LocationService RetransT imer StoreF orwardlif et ime StoreF orwardm axsize T raf f ichoplimit P ositionv ector GeoDestination Description This object indicates whether the GeoNetworking function is enabled. This object indicates GN_ADDR in [ETSI-TS ] that could be updated for privacy reasons (i.e. pseudonym). The index to uniquely identify the interface between GeoNetworking and IP. The index to uniquely identify the interface between GeoNetworking and Access. ex. egress interface. This object indicates the default lifetime of the entry in the location table. This object indicates the maximum number of the nodes storing in the location table. This object indicates the entries of location table. This object indicates the default time interval of beacons. This object indicates the default hop limit of beacons. The object indicates the default type of Location Service (ex. flooding, request-reply, etc.) This object indicates default hop limit of location service message. The objects indicates the default time interval to resend the request of Location Service. The object indicates the lifetime of storing packets, when the node is out of destination area. This object indicates the maximum size of packet stored in the node for store and forward. This object indicates default hop limit of traffic packet. The object indicates the position vector of the ITS-S. The object indicates the mapping between group ID and geographic destination area. Figure 14.2: N-Parameters for GeoNetworking GeoCapability and GeoN odeid are defined as basic setting. The management entity determines whether the GeoNetworking function is enabled or not using GeoEnableStatus. Also, it can enable and disable the GeoNetworking function using GeoEnableStatus. GeoN odeid indicates the GeoNetworking ID (GN_ADDR in [ETSI-TS ]) used in the ITS station. For preventing the location privacy issue, the management entity may change the 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. GeoAccessInterf aceindex and GeoIpInterf aceindex are defined as CI parameters. GeoAccessInterf aceindex indicates the index of the egress interface of GeoNetworking and GeoIpInterf aceindex indicates the index of virtual interface between GeoNetworking and IP. The former object is mandatory for all the GeoNetworking nodes because all of them have the egress interface. On the other hand, later object is used only in IPv6 GeoNetworking, when GeoNetworking gives the packet to the IP layer or vice versa. These objects only ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 110/134

112 provides the interface index, however the management entity can find corresponding locator and identifier (i.e. IP address or prefix information) of the ITS Station by the interface index using MIB for IP. LocationT ablelif et ime, LocationT ablem axn ode and LocationT ableentry are defined as LT parameters. LocationT ablelif et ime indicates the default lifetime of the Location Table entries. When neighbor nodes are moving fast and are organizing very dynamic network topologies, a neighbor ITS Station position kept as a Location Table entry cannot be fresh for long time. Thus the lifetime of Location Table should be configured shorter. LocationT ablem axn ode indicates the maximum number of nodes stored in the Location Table. In a traffic jam situation, many neighbor ITS Station position stored in the Location Table amplifies the calculation time of the next hop GeoNetworking node. The management entity can set proper number of nodes in Location Table to avoid performance degradation. LocationT ableentry indicates the entries of Location Table. The management entity get the position information of neighbor GeoNetworking nodes including GeoNetworking ID, latitude, longitude, altitude, speed, heading and lifetime. BeaconInterval and BeaconHopLimit are defined as beacon parameters. BeaconInterval indicates the time interval between beacons. In the GeoNetworking layer, the position of the ITS Station should be updated frequently because the Location Table entry in the neighbor node cannot be fresh. On the other hand, in case of traffic jam, the frequent updates of the Location Table entries are not necessary, in contrary, the frequent beacons from many GeoNetworking node cause congestion of traffic. Thus in low-speed situation, longer time interval between beacons is favorable. BeaconHopLimit indicates the hop limit of the beacons. Normally, the hop limit is set as 1, however multi-hop beaconing is considered as an advanced feature of GeoNetworking. Multi-hop beaconing allows a GeoNetworking node to get the position of neighbors several hops away. In packet transmission, the node can avoid to send Location Service request when it has the position of the destination node in Location Table. Thus multi-hop may improve the delay by increasing the possibility to avoid Location Service signaling. There is a trade-off between the delay and network traffic congestion because of beacon flooding. LocationServiceT ype, LocationServiceHopLimit and LocationServiceRetransT imer are defined as Location Service parameters. LocationServiceT ype indicates the default Location Service type including the flooding and request-reply signaling. The management 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 of resending Location Service request when the node has no Location Service reply. StoreF orwardinglif et ime, StoreF orwardingm axsize and T raf f ichoplimit are defined as forwarding parameters,. StoreF orwardinglifet ime indicates the lifetime of stored packets when the destination node is not its neighbor. The stored packets can be delivered to a longer distance with longer lifetime of storing packets. Thus it increases possibility to reach the destination, however there are a trade-off between memory for storing packets and calculation time in the forwarding table. StoreF orwardingm axsize indicates the maximum total size of stored packets. T raffichoplimit indicates the default hop limit of traffic packet. P ositionv ector and GeoDestination are defined as the other parameters. P ositionv ector indicates the position vector of the nodes including latitude, longitude, altitude, speed, heading and lifetime. GeoDestination indicates the mapping between multicast address and the geographical destination area (GeoDestination) defined in [ETSI-EN ]. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 111/134

113 14.3 Parameters and primitives for path and flow management MN-REQUEST and MN-COMMAND In this section, we propose new MN-REQUEST commands and MN-COMMAND commands that 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 the MN-REQUEST commands defined for the SNT to notify the SME about the network status, depending on type of information. A more detailed description is provided in the following sub sections. Command name STAGeoNot STATopoNot STAServNot PathNot PathMetricNot FlowStatistics Description Notification of geographic information of an ITS station. Notification of topological locator of an ITS station. Notification of service of an ITS station Notification of status of a path Notification of network metric of a path Provide network flow statistics. Table 14.5: New MN-REQUESTs Table 14.6 presents the MN-COMMAND commands defined for the SME to instruct the SNT. A more detailed description is provided in the following sub sections. COMMAND name PathMNGT FlowClassificationRule FlowPolicy FlowFeedback STAServDiscov Description Command for managing a path Attribute an identifier to each packet that is output or forwarded by ITS Station. Set flow policy for the currently available paths in local and neighbor ITS stations. Request flow statistics from the network. 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 SME and the horizontal layers. Details are provided in Chapter MN-REQUEST STAGeoNot MN-Request.STATopoNot shall be used by the SNT to notify the geographical position information of an ITS station to the SME. Table 14.7 shows the parameters of STATopoNot.. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 112/134

114 SAP Function parameter Information SAP Management Flow requirement table MF- SAP MF-REQUEST ITS-S-Appl-Reg [ISO_24102] Flow req & Flow stat Flow requirement list MF- SAP Facilities Flow Information table Flow statistics table MN-REQUEST FlowStatNot Flow Statistics ITS-S information Network & Transport Flow Policy table ITS-S Basic info Local ITS-S Information table Neighbor ITS-S Information table MF- SAP MN- SAP STAGeoNot STATopoNot STAServNot PathNot Geographic Position Topological Information Service Path Information Path Status MN- SAP Path Information table Path and Flow Management MI- SAP MN- SAP PathMetricNot MI-REQUEST Event [ISO_24102] MN-COMMAND PathMNG STAServDiscov FlowClassRule Network Metric Interface Path Infomation ITS-S Information Flow Flow Classification Rule MI- SAP MN- SAP Access Network & Transport FlowPolicy Flow Policy FlowMonitor Flow Statistics Figure 14.3: Cross-layer information flow for path and flow management MN-REQUEST STATopoNot MN-Request.STATopoNot shall be used by the SNT to notify the topological locator information of an ITS station to the SME. Table 14.8 describes parameters of STATopoNot MN-REQUEST STAServNot MN-Request.STAServNot shall be used by the SNT to notify the service information of an ITS station to the SME. Table 14.9 shows the parameters of STAServNot. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 113/134

115 ASN.1 Type Valid Range Description MN-Request.STAGeoNot Notification of geographic information of an ITS Station STAGeoNot.ITS-scuId ITS-scuId ITS-SCU-ID of an ITS station at the geographical position reported in the request. STAGeoNot.latitude 32 bit signed integer WGS-84 latitude of the ITS station expressed in 1/10 micro degree. STAGeoNot.longitude 32 bit signed integer WGS-84 longitude of the ITS station expressed in 1/10 micro degree. STAGeoNot.altitude 16 bit signed integer Altitude of the ITS station expressed in signed units of 1 meter. STAGeoNot.speed 16 bit signed integer Speed of the ITS station expressed in signed units of 0.01 meter per second. STAGeoNot.heading 16 bit unsigned integer Heading of the ITS station expressed in unsigned units of 0.1 degrees from North. STAGeoNot.accuracy 16 bit unsigned integer Accuracy indicator of the geographical position of the ITS station STAGeoNot.timestamp UTC The time when the corresponding geographical position is recorded in units of seconds. STAGeoNot.lifetime 16 bit unsigned integer (Optional) The expiration time of the corresponding geographical position entry in units of seconds. Table 14.7: Parameters of MN-REQUEST STAGeoNot ASN.1 Type Valid Range Description MN-Request.STATopoNot Notification of the network topology locator of an ITS station STATopoNot.ITS-scuId ITS-scuId ITS-SCU-ID of the ITS station that has the network topology locator reported in the request. STATopoNot.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it is the network part (first 64bits) of an IP address that indicates the location of the node in the network topology. Table 14.8: Parameters of MN-REQUEST STATopoNot MN-REQUEST PathNot MN-Request.PathNot shall be used by the SNT to notify the status of a path to the SME. Table shows the parameters of PathNot. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 114/134

116 ASN.1 Type Valid Range Description MN-Request.STAServNot Notification of the service of an ITS station STAServNot.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 Gateway DHCP Qos TBD Table 14.9: Parameters of MN-REQUEST STAServNot ASN.1 Type Valid Range Description MN-Request.pathNot Notification of status of a path PathNot.localCIID 64 bits permanent, ex. EUI-64 or generated with the way in ISO21218 PathNot.remoteCIID 64 bits dynamic, ex. EUI-64 of remote CI (last hop) or a serial number according to the access technology) (Can be dynamic or static ISO21218) PathNot.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it is the network part (first 64bits) of an IP address that indicates the 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 a border router when packet goes beyond the network managed by a local routing protocol. (ex. MR or AR in the case of the path from the vehicle ITS Station) PathNot.anchor ITS-scuId ITS-SCU-ID of an ITS station that provides Locator registration function to ITS-S. PathNot.reachability 16 bit flags Network topology distance indicator from the CI on-link ITS domain Local Network Extended Local PathNot.capabilities 64 bit flags Capabilities offered on the path, e.g. Reverse reachability for host Session continuity for host Reverse reachability for network Session continuity for network Global Network TBD 1-to-n for group 1-to-n for GeoArea QoS TBD PathNot.status 16 bit flags Status of the path. 0: not available 2: ready to be used 4: going to up 1: being used 3: potentially ready 5: going to down Table 14.10: Parameters of MN-REQUEST PathNot MN-REQUEST PathMetricNot MN-Request.PathMetricNot shall be used by the SNT to notify path metrics to the SME. Table shows the parameters of MN-Request.PathMetricNot. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 115/134

117 ASN.1 Type Valid Range Description MN-Request.pathMetricNot Notification of network metric of a path PathMetricNot.Payload Size of payload for a packet using the path. PathMetricNot.Delay A trip time that the path has, and actual round trip time to reach to the node in the destination scope PathMetricNot.Hop Number of hops to reach to the destination. Table 14.11: Parameters of MN-REQUEST PathMetricNot MN-REQUEST FlowStatistics MN-Request.FlowStatistics shall be used by the SNT to notify network statistics to the SME. Table shows the parameters of FlowStatistics. ASN.1 Type Valid Range Description MN-Request.flowStatistics Provide network from statistic informations. FlowStatistics.commMode FlowStatistics.destination FlowStatistics.source node/group/geoarea Communication mode of the reported Node ID/group ID/geoArea ID ITS Station Node ID connection. Destination of the reported connection. Source of the reported connection. FlowStatistics.protocol Protocol ID Network protocol ID of the reported connection FlowStatistics.protocolInfo 1024 bit blob Protocol-specific information FlowStatistics.flowID Flow ID Classification currently issued for traffic from this connection FlowStatistics.pathID Path ID Path currently used for traffic from this FlowStatistics.datarate FlowStatistics.pps 32 bit unsigned integer 16 bit unsigned integer connection Datarate of this connection in bits/seconds Packets per seconds of this connection Table 14.12: Parameters of MN-REQUEST FlowStatistics MN-COMMAND PathMNGT MN-Command.PathMNGT shall be used by the SME to request management of a path, that includes establishment, removal of a path or change of the path parameters (the locator, the nexthop and the anchor, etc.). Table shows the parameters of PathMNGT MN-COMMAND FlowClassificationRule MN-Command.FlowClassificationRule" shall be used by the SME to define classification rules to be applied in the ITS station. Table shows the parameters of FlowClassificationRule MN-COMMAND FlowPolicy MN-Command.FlowPolicy shall be used by the SME to request enforcement of flow policy in the local ITS station. Table shows the parameters of FlowPolicy. ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 116/134

118 ASN.1 Type Valid Range Description MN-Command.pathMNGT Notification of status of a path PathMNGT.linkID Link-ID of CI Link ID of the CI where the path starts from PathMNGT.locator 64 bit integer Network topology locator of the ITS-S. In IPv6, it is the network part (first 64bits) of an IP address that indicates the location of the node in the network topology. PathMNGT.nexthop ITS-scuId ITS-SCU-ID of an ITS station on the path that is a border between wireless network and wired network. (ex. MR or AR in the case of the path from the vehicle ITS Station) PathMNGT.anchor ITS-scuId ITS-SCU-ID of an ITS station that provides Locator registration function to local ITS-S. PathMNGT.reachability 16 bit flags Topological distance indicator from the CI on-link ITS domain Local Network Extended Local Global Network TBD Table 14.13: Parameters of MN-COMMAND PathMNGT ASN.1 Type Valid Range Description MN-Command.flowClassificationRule Management of flow classification. FlowClassificationRule.commMode node/group/ geoarea FlowClassificationRule.destination Node ID / FlowClassificationRule.source group ID/ geoarea ID ITS station Node ID Communication mode used by the packet. Destination of the packet. Source of the packet. FlowClassificationRule.protocol Protocol ID Network protocol ID FlowClassificationRule.protocolInfo 1024 bit blob Protocol-specific information FlowClassificationRule.flowID Flow ID Classification issued by this rule Table 14.14: Parameters of MN-COMMAND FlowClassificationRule MN-COMMAND FlowFeedback MN-Command.FlowFeedback shall be used by the SME to request statistics from the SNT. Table shows the parameters of FlowFeedback MN-COMMAND STAServDiscov MN-Command.STAServDiscov shall be used by the SME to request discovery of services. Table shows the parameters of STAServDiscov. For example, in the IPv6 protocol block of the SNT, the service discovery triggers Router Solicitation, Neighbor Solicitation in NDP to discover new ARs and new neighbors when service field is specified as discovery of access and neighbor. Or Anchor service discovery is specified in service field of ServDiscov, it is translated into Dynamic Home Agent Address Discovery request in NEMO. The cycle of the path selection manager returns to the candidate path calculation because another candidate path may appears as a result of service discovery ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 117/134

119 ASN.1 Type Valid Range Description MN-Command.flowPolicy Management of the flow policy table. FlowPolicy.action add / modify / Action to perform on flow policies del / flush FlowPolicy.flowID Flow ID An identifier to distinguish a flow. Flow ID is the classification issued on each packet by Flow Classification Rules. FlowPolicy.pathID Path ID unique ID to identify a path FlowPolicy.priority priority of the policy. The higher it is the more the rule is prioritized. Table 14.15: Parameters of MN-COMMAND FlowPolicy ASN.1 Type Valid Range Description 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). ASN.1 Type Valid Range Description MN-Command.sTAServDiscov Discover an ITS Station that can provide a service STAServDiscov.service 64 bits flags The services that the ITS-S can provide to self ITS-S. DNS server Multicast Listener Location registration Gateway DHCP Qos TBD Table 14.17: Parameters of MN-COMMAND STAServDiscov ITSSv6 - IPv6 ITS Station Stack for Cooperative ITS FOTs 118/134

120 CHAPTER 15 SN-SAP: Interface between Networking & Transport Layer and Security Entity 15.1 Overview Fig shows the message flow involving the SN-SAP whenever messages pass the SNT for security services. The SSE acts like a layer inside the SNT, i.e., it is called during the processing of messages traversing the SNT. The security entity does not act as a layer above or below the SNT, i.e., interactions with facilities and access layers are achieved via other SAPs. 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