Specification of the End-To-End ATM Network Simulator

Transcription

1 Specification of the End-To-End ATM Network Simulator Deliverable D19 PROJECT INFORMATION Project Name NEWSKY Networking the Sky for Aeronautical Communications EC Instrument Specific Targeted Research Project (STREP) within FP6 Call AERO G (Innovative ATM Research) Contract Number Project Duration 26/02/ /09/2009 (30 months) Project Coordinator Project Partners German Aerospace Center (DLR) Thales Alenia Space France (TASF), QinetiQ Ltd, University of Salzburg (UniSBG), Frequentis GmbH (FRQ), TriaGnoSys GmbH (TGS), Deutsche Flugsicherung GmbH (DFS) DOCUMENT INFORMATION Title Specification of the End-To-End ATM Network Simulator Version 1.1 Work Package WP4 Dissemination Level PU DOCUMENT AUTHORS AND AUTHORIZATION Document Responsible Contributors Thomas Gräupl, USBG Max Ehammer (USBG) Christian Bauer, Christian Kissling, Felix Hoffmann (DLR) Released by Frank Schreckenbach (DLR) Date: Project co-funded by the European Commission within the 6th Framework Programme

2 DOCUMENT HISTORY Version Date Modified Contents Implemented by First issue T. Gräupl Update according to EC comments T. Gräupl Specification of the End-To-End ATM Network Simulator Page: I

3 Contents 1 Executive Summary Introduction Overview of the NEWSKY Project Scope of the Document Guidance to Documentation Simulation Scenarios Network Load Model ATS Traffic Model AOC Traffic Model NET Traffic Model AAC Traffic Model APC Traffic Model HTTP Traffic Traffic VoIP Traffic Constant Bit Rate Traffic Network Functionality Model Overview Network Topology Resource Management Concepts Scheduling Link Selection Transport Layer Advanced Routing Concepts Neighbor Discovery Stateless Autoconfiguration Mobility Support in IPv6 (MIPv6) Network Mobility (NEMO) Specification of the End-To-End ATM Network Simulator Page: II

4 4.4.5 Global HA to HA Proxy Mobile IPv6 (PMIPv6) Seamless Handover Strategies Media Independent Handover Function Simulation Software Design and Integration NEWSKY end-to-end simulation model Simulation Scenario Settings Simulation Scenario High Level Overview Key Issues of Implementation Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Configurable Parameters Key Observations of Scenario Simulation Scenario Simulation Scenario High Level Overview Key Issues of Implementation Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Key Issues of Implementation Configurable Parameters Key Observations of Scenario Key Observations in intercontinental Scenario Simulation Scenario High Level Overview Specification of the End-To-End ATM Network Simulator Page: III

5 Key Issues of Implementation Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Configurable Parameters Key Observations of Scenario Simulation Scenario 9 & Simulation Scenario 11 & Key Issues of Implementation Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Key Issues of Implementation Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Configurable Parameters Key Observations of Scenario Simulation Scenario Simulation Scenario High Level Overview Configurable Parameters Key Observations of Scenario Simulation Scenario High Level Overview Key Issues of Implementation Configurable Parameters Key Observations of Scenario Results Acronyms and Abbreviations Specification of the End-To-End ATM Network Simulator Page: IV

6 8 References Appendix A - Deviations from D16 and D Appendix B Detailed Protocol Descriptions IEEE Primitives MIH_LINK_SAP & MIH_SAP MIH_LINK_SAP MIH_ SAP Handover Related Primitives MIH_Link_Going_Down MIH_Link_Down MIH_Link_Up MIH_Link_Detected MIH_Link_Actions Event & Command IDs RFC 4861: Neighbor Discovery for IP version 6 (IPv6) Introduction Protocol Specification RFC 4862: IPv6 Stateless Address Autoconfiguration Introduction Protocol Specification RFC 3775: Mobility Support in IPv Introduction Protocol Specification Bootstrapping RFC 3963: NEMO Introduction Protocol Specification Draft: Global HA to HA Introduction Overview MR Registration Locating appropriate HA Specification of the End-To-End ATM Network Simulator Page: V

7 MR binding to HA Basic HA operation HA to HA Synchronization Proactive Synchronization RFC 5213: Proxy Mobile IPv Introduction Protocol specification Simplified Multihoming Protocol for Link Selection Algorithms Simple Link Selection (without multihoming) Dynamic Link Selection (with multihoming) Appendix C Implementation of COCR Data Traffic Model Conditions for message exchange Message Triggers Domain Phase Position Number of exchanges Probability of exchange Aircraft type Description of message exchange Type of Service Forward Link and Reverse Link Message Sizes and Quantities Class of Service - Performance Requirements Assumptions Air Traffic Sectors and Domains ORP Domain Air Traffic Service Units Triggering of message exchanges Message exchange initiation Examples Implementations ACL D-OTIS Implemented COCR ATS Services Specification of the End-To-End ATM Network Simulator Page: VI

8 11.6 Implemented COCR AOC Services Implemented COCR NET Services Appendix D ATS Service Descriptions Data Communication Management Services (DCM) Data Link Logon (DLL) Conditions for DLL Message Exchange Message Exchange Description ATC Communciation Management (ACM) Conditions for ACM Message Exchange Message Exchange Description Clearance / Instruction Services (CIS) ATC Clearance (ACL) Conditions for ACL Message Exchange Message Exchange Description Departure Clearance (DCL) Conditions for DCL Message Exchange Message Exchange Description Downstream Clearance (DSC) Conditions for DSC Message Exchange Message Exchange Description Data Link Taxi (D-TAXI) Conditions for D-TAXI Message Exchange Message Exchange Description Common Trajectory Coordination (COTRAC) Conditions for COTRAC Message Exchange Message Exchange Description Flight Information Services (FIS) Data Link Automatic Terminal Information Service (D-ATIS) Conditions for D-ATIS Message Exchange Message Exchange Description Data Link Operational Terminal Information Service (D-OTIS) Conditions for D-OTIS Message Exchange Message Exchange Description Data Link Operational En Route Information Service (D-ORIS) Specification of the End-To-End ATM Network Simulator Page: VII

9 Conditions for D-ORIS Message Exchange Message Exchange Description Data Link Significant Meteorological Information (D-SIGMET) Conditions for D-SIGMET Message Exchange Message Exchange Description Data Link Runway Visual Range (D-RVR) Conditions for D-RVR Message Exchange Message Exchange Description Data Link Surface Information and Guidance (D-SIG) Conditions for D-SIG Message Exchange Message Exchange Description Advisory Services (AVS) Arrival Manager Information Delivery (ARMAND) Conditions for ARMAND Message Exchange Message Exchange Description Dynamic Route Availability (DYNAV) Conditions for DYNAV Message Exchange Message Exchange Description Data Link Flight Update (D-FLUP) Conditions for D-FLUP Message Exchange Message Exchange Description Flight Position / Intent / Preferences Services (FPS) Flight Plan Consistency (FLIPCY) Conditions for FLIPCY Message Exchange Message Exchange Description Flight Path Intent (FLIPINT) Conditions for FLIPINT Message Exchange Message Exchange Description System Access Parameters (SAP) Conditions for SAP Message Exchange Message Exchange Description Pilot Preferences Downlink (PPD) Conditions for PPD Message Exchange Emergency Information Services (EIS) Data Link Alert (D-ALERT) Specification of the End-To-End ATM Network Simulator Page: VIII

10 Conditions for D-ALERT Message Exchange Message Exchange Description Urgent Contact (URCO) Conditions for URCO Message Exchange Message Exchange Description Delegated-Separation Services (DSS) In-Trail Procedures (ITP) Conditions for ITP Message Exchange Message Exchange Description Merging and Spacing (M&S) Conditions for M&S Message Exchange Message Exchange Description Paired Approach (PAIRAPP) Conditions for PAIRAPP Message Exchange Message Exchange Description Crossing and Passing (C&P) Conditions for C&P Message Exchange Message Exchange Description Miscellaneous Services (MIS) Air-to-Air Self Separation (AIRSEP) Conditions for AIRSEP Message Exchange Message Exchange Description Auto Execute (A-EXEC) Conditions for A-EXEC Message Exchange Message Exchange Description Appendix E - AOC Service Descriptions AOC Data Link Logon (AOCDLL) Conditions for AOCDLL Message Exchange Message Exchange Description Out-Off-On-In (OOOI) Conditions for OOOI Message Exchange Message Exchange Description Notice to Airmen (NOTAM) Conditions for NOTAM Message Exchange Specification of the End-To-End ATM Network Simulator Page: IX

11 Message Exchange Description Free Text (FREETEXT) Conditions for FREETEXT Message Exchange Message Exchange Description Textual Weather Reports (WXTEXT) Conditions for WXTEXT Message Exchange Message Exchange Description Position Report (POSRPT) Conditions for POSRPT Message Exchange Message Exchange Description Flight Status (FLTSTAT) Conditions for FLTSTAT Message Exchange Message Exchange Description Fuel Status (FUEL) Conditions for FUEL Message Exchange Message Exchange Description Gate and Connecting Flight Status (GATES) Conditions for GATES Message Exchange Message Exchange Description Engine Performance Reports (ENGINE) Conditions for ENGINE Message Exchange Message Exchange Description Maintenance Problem Resolution (MAINTPR) Conditions for MAINTPR Message Exchange Message Exchange Description Flight Plan Data (FLTPLAN) Conditions for FLTPLAN Message Exchange Message Exchange Description Load Sheet Request / Transfer (LOADSHT) Conditions for LOADSHT Message Exchange Message Exchange Description Flight Log Transfer (FLTLOG) Conditions for FLTLOG Message Exchange Message Exchange Description Real Time Maintenance Information (MAINTRT) Specification of the End-To-End ATM Network Simulator Page: X

12 Conditions for MAINTRT Message Exchange Message Exchange Description Graphical Weather Information (WXGRAPH) Conditions for WXGRAPH Message Exchange Message Exchange Description Real-time Weather Reports for Met Office (WXRT) Conditions for WXRT Message Exchange Message Exchange Description Technical Log Book Update (TECHLOG) Conditions for TECHLOG Message Exchange Message Exchange Description Cabin Log Book Transfer (CABINLOG) Conditions for CABINLOG Message Exchange Message Exchange Description Update Electronic Library (UPLIB) Conditions for UPLIB Message Exchange Message Exchange Description Software Loading (SWLOAD) Conditions for SWLOAD Message Exchange Message Exchange Description Appendix F NET Service Descriptions Network Connection (NETCONN) Conditions for NETCONN Message Exchange Message Exchange Description Network Keep-Alive (NETKEEP) Conditions for NETKEEP Message Exchange Message Exchange Description Illustrations Figure 2-1: General outline of NEWSKY evaluation process Figure 4-1: Overview of network topology Figure 5-1: Graphical representation of topology data Specification of the End-To-End ATM Network Simulator Page: XI

13 Figure 5-2: Protocol stack visualization of SIM Figure 5-3: Protocol stack visualization of SIM Figure 5-4: Protocol stack visualization of SIM Figure 5-5: Protocol stack visualization of SIM Figure 5-6: Protocol stack visualization of SIM Figure 5-7: Protocol stack visualization of SIM Figure 5-8: Protocol stack visualization of SIM 11 & SIM Figure 5-9: Protocol visualization of SIM Figure 5-10: Stack visualization of SIM Figure 5-11: Stack visualization of SIM Figure 10-1 Partial view of protocol stack with MIHF and interfaces Figure 10-2 MIHF Event propagation Figure 10-3 MIHF Command propagation Figure 10-4 Signalling: Address Resolution Figure 10-5 Signalling: Neighbor Unreachability Detection Figure 10-6 Signalling: Router Discovery Figure 10-7 Signalling: Movement Detection, DAD and BU/BA exchange Figure 10-8 Global HA to HA network structure Figure 10-9 DHAAD signalling Figure Signalling for and traffic forwarding after HA synchronization Figure Proactive RO between LMAs Figure Flow chart of the simple link selection algorithm Figure General flow of the dynamic link selection algorithm Figure Pre-screening phase of the link selection algorithm Figure 11-1: Flight domains as used in the data traffic simulation Figure 11-2: FRS Boundary Point Examples Figure 11-3: ORP region (blue) according to COCR and DAFIF Figure 11-4: COCR interpretation for ACL Figure 11-5: USBG interpretation for D-OTIS Tables Table 2-1: Guidance to documentation Overview Table 2-2: Guidance to documentation Detailed descriptions Table 2-3: Simulation scenarios Specification of the End-To-End ATM Network Simulator Page: XII

14 Table 3-1: COCR ATS data link services Table 3-2: COCR AOC data link services Table 3-3: COCR NET data link services Table 3-4: Current AAC Applications Table 3-5: Future AAC Applications Table 3-6: Probabilities of service use by passengers Table 4-1: List of NEWSKY specified protocols implemented for simulations Table 4-2: Mapping of simulation scenarios to protocols/algorithms Table 4-3: Mapping of CoS to DiffServ aggregates Table 5-1: Preference table for simple link selection Table 5-2: Configurable parameters of SIM Table 5-3: Configurable parameters of SIM Table 5-4: Changed parameter settings in comparison to SIM Table 5-5: Configurable parameters of SIM Table 5-6: Changed parameter settings in comparison to SIM Table 5-7: Used preference table for the simulations Table 5-8: Configurable parameters for SIM Table 5-9: Changed parameter settings in comparison to SIM Table 6-1: Simulation input files Table 6-2: Simulation reports Table 9-1: Home agent coverage Table 10-1 User preference table Table 10-2 User preference table Table 11-1: COCR domain definitions Table 11-2: COCR classes of service Table 11-3: Excerpt from Table 6-15 (COCR) Table 11-4: Excerpt from Table 6-2 (COCR) Table 11-5: ATS services Table 11-6: AOC services Table 11-7: NET services Table 12-1: Phase 1 conditions Table 12-2: Phase 2 conditions Table 12-3 Message Sizes and Quantities Type I + II Table 12-4 Performance Requirements Table 12-5 Phase 1 conditions Specification of the End-To-End ATM Network Simulator Page: XIII

15 Table 12-6 Phase 2 conditions Table 12-7: Message Sizes and Quantities Type I + II Table 12-8 Performance Requirements Table 12-9: Phase 1 conditions Table 12-10: Phase 2 conditions Table 12-11: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-13: Phase 1 conditions Table 12-14: Phase 2 conditions Table 12-15: Message Size and Quantities Type I + II Table Performance Requirements Table 12-17: Phase 1 conditions Table 12-18: Phase 2 conditions Table 12-19: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-21: Phase 1 conditions Table 12-22: Phase 2 conditions Table 12-23: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-25: Phase 2 conditions Table 12-26: Message Sizes and Quantities Type II for COTRAC Interactive Table 12-27: Message Sizes and Quantities Type II for COTRAC Wilco Table Performance Requirements Table 12-29: Phase 1 conditions Table 12-30: Phase 2 conditions Table 12-31: Message Sizes and Quantities Type I + II D-ATIS Arrival Table 12-32: Message Sizes and Quantities Type I + II D-ATIS Departure Table Performance Requirements Table 12-34: Phase 1 conditions Table 12-35: Phase 2 conditions Table 12-36: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-38: Phase 1 conditions Table 12-39: Phase 2 conditions Table 12-40: Message Sizes and Quantities Type I + II Specification of the End-To-End ATM Network Simulator Page: XIV

16 Table Performance Requirements Table 12-42: Phase 1 conditions Table 12-43: Phase 2 conditions Table 12-44: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-46: Phase 1 conditions Table 12-47: Phase 2 conditions Table 12-48: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-50: Phase 1 conditions Table 12-51: Phase 2 conditions Table 12-52: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-54: Phase 1 conditions Table 12-55: Phase 2 conditions Table 12-56: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-58: Phase 2 conditions Table 12-59: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-61: Phase 1 conditions Table 12-62: Phase 2 conditions Table 12-63: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-65: Phase 1 conditions Table 12-66: Phase 2 conditions Table 12-67: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-69: Phase 1 conditions Table 12-70: Phase 2 conditions Table 12-71: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-73: Phase 1 conditions (Contract Setup) Table 12-74: Phase 1 conditions (Report) Table 12-75: Phase 2 conditions (Contract Setup) Specification of the End-To-End ATM Network Simulator Page: XV

17 Table 12-76: Phase 2 conditions (Contract Setup) Table 12-77: Message Sizes and Quantities Type I + II (Contract Setup) Table 12-78: Message Sizes and Quantities Type I + II (Report) Table Performance Requirements Table 12-80: Phase 1 conditions Table 12-81: Phase 2 conditions Table 12-82: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-84: Phase 1 conditions Table 12-85: Phase 2 conditions Table 12-86: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-88: Phase 2 conditions Table 12-89: Message Sizes and Quantities Type I + II Table Performance Requirements Table 12-91: Phase 1 conditions addressed (ACL) Table 12-92: Phase 1 conditions Broadcast (SURV) Table 12-93: Phase 2 conditions adressed (ACL) Table 12-94: Phase 2 conditions Broadcast (SURV) Table 12-95: Message Sizes and Quantities Type I Addressed Table 12-96: Message Sizes and Quantities Type I Broadcast Table Performance Requirements (ITP ACL) Table Performance Requirements (ITP SURV) Table 12-99: Phase 1 conditions addressed (ACL) Table : Phase 1 conditions Broadcast (SURV) Table : Phase 2 conditions addressed (ACL) Table : Phase 2 conditions Broadcast (SURV) Table : Message Sizes and Quantities Type I Addressed Table : Message Sizes and Quantities Type I Broadcast Table Performance Requirements (M&S ACL) Table Performance Requirements (M&S SURV) Table : Phase 2 conditions addressed (ACL) Table : Phase 2 conditions Broadcast (SURV) Table : Message Sizes and Quantities Type I Adressed Table : Message Sizes and Quantities Type I Broadcast Specification of the End-To-End ATM Network Simulator Page: XVI

18 Table Performance Requirements (PAIRAPP ACL) Table Performance Requirements (PAIRAPP SURV) Table : Phase 1 conditions addressed (ACL) Table : Phase 1 conditions Broadcast (SURV) Table : Phase 2 conditions addressed (ACL) Table : Phase 2 conditions Broadcast (SURV) Table : Message Sizes and Quantities Type I Addressed Table : Message Sizes and Quantities Type I Broadcast Table Performance Requirements (C&P ACL) Table Performance Requirements (C&P SURV) Table : Phase 2 conditions addressed Table Phase 2 conditions broadcast Table : Message Sizes and Quantities Type II Adressed Table : Message Sizes and Quantities Type II Broadcast Table Performance Requirements Addressed Table Performance Requirements Broadcast Table : Phase 2 conditions Table : Message Sizes and Quantities Type II Table Performance Requirements Table 13-1: Phase 1 and 2 conditions Table 13-2: Message Sizes and Quantities Type I + II Table 13-3 Performance Requirements Table 13-4: Phase 1 and 2 conditions Table 13-5: Message Sizes and Quantities Type I + II Table 13-6 Performance Requirements Table 13-7: Phase 1 and 2 conditions Table 13-8: Message Sizes and Quantities Type I + II Table 13-9 Performance Requirements Table 13-10: Phase 1 conditions Table 13-11: Phase 2 conditions Table 13-12: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-14: Phase 1 conditions Table 13-15: Phase 2 conditions Table 13-16: Message Sizes and Quantities Type I + II Specification of the End-To-End ATM Network Simulator Page: XVII

19 Table Performance Requirements Table 13-18: Phase 1 conditions Table 13-19: Phase 2 conditions Table 13-20: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-22: Phase 1 conditions Table 13-23: Phase 2 conditions Table 13-24: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-26: Phase 1 conditions Table 13-27: Phase 2 conditions Table 13-28: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-30: Phase 1 and 2 conditions Table 13-31: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-33: Phase 1 and 2 conditions Table 13-34: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-36: Phase 1 conditions Table 13-37: Phase 2 conditions Table 13-38: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-40: Phase 1 conditions Table 13-41: Phase 2 conditions Table 13-42: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-44: Phase 1 and 2 conditions Table 13-45: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-47: Phase 1 and 2 conditions Table 13-48: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-50: Phase 1 conditions Table 13-51: Phase 1 conditions Specification of the End-To-End ATM Network Simulator Page: XVIII

20 Table 13-52: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-54: Phase 1 conditions Table 13-55: Phase 2 conditions Table 13-56: Phase 1 Message Sizes and Quantities Type I + II Table 13-57: Phase 2 Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-59: Phase 1 conditions Table 13-60: Phase 2 conditions Table 13-61: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-63: Phase 1 and 2 conditions Table 13-64: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-66: Phase 1 and 2 conditions Table 13-67: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-69: Phase 1 and 2 conditions Table 13-70: Message Sizes and Quantities Type I + II Table Performance Requirements Table 13-72: Phase 1 and 2 conditions Table 13-73: Message Sizes and Quantities Type I + II Table Performance Requirements Table 14-1: Phase 1 conditions Table 14-2: Phase 2 conditions Table 14-3: Message Sizes and Quantities Type I + II Table 14-4: Phase 1 conditions Table 14-5: Phase 2 conditions Table 14-6: Message Sizes and Quantities Type I + II Specification of the End-To-End ATM Network Simulator Page: XIX

21 1 Executive Summary This document is the deliverable D19 Specification of the ATM End-To-End Simulator of the NEWSKY project and is the output of WP4.3 End-to-End ATM Network Simulator. The networking concepts developed within NEWSKY project were validated by two means: extensive computer simulation, and laboratory demonstration. This document focuses on the computer simulations. The simulation based NEWSKY concept validation activity comprised the development of the software simulators and the execution of the simulations. The first stage of the simulation was the generation of realistic air traffic patterns. This was based on EUROCONTROL Central Flow Management Unit (CFMU) data within Europe and flight schedules for areas outside of Europe (which was not the main focus of NEWSKY). The air traffic was extrapolated to the year 2025 on the basis of the EUROCONTROL mediumterm and long-term forecasts [17][26]. In the second step the link characteristics between different network nodes of the terrestrial, airborne, and satellite segments of the NEWSKY network were investigated in large-scale topology simulations [29]. The relevant wireless link technologies were identified during earlier phases of the project [2]; within the simulations each link technology was simulated with simplified characteristics. In the next step the aircraft, base-stations, and satellites were interconnected using a synthetic ground infrastructure. The details of this infrastructure were derived from the typical inter-relations of aeronautical communication services providers. This network topology constituted the simulation environment for the end-to-end simulation of NEWSKY. The end-to-end simulation comprised the simulation of different data link applications (network load models) and different network protocols (network functionality model). The network load model simulated a mix of potential future aeronautical data link applications for air traffic management (ATM), airline operational control (AOC), airline administrative communication (AAC), and airline passenger communication (APC). The network functionality model comprised the NEWSKY protocol stack as it was defined in WP3. This document provides the detailed descriptions of the network load models and the network functionality models. The simulation of the NEWSKY applications (ATC, AOC, AAC, and APC) and networking protocols provided the necessary input to perform the end-to-end validation in WP 4.4. Specification of the End-To-End ATM Network Simulator Page: 1-1

22 2 Introduction 2.1 Overview of the NEWSKY Project Global situation awareness will be a result of improved information availability and sharing, which is one of the key enablers for future aeronautical systems. To achieve this goal, the NEWSKY project aims to develop a concept for a global communication network for aeronautics. Efficient and reliable communication systems are required to support the expected sustainable growth of European air transport. However, aeronautical communication technologies are already running at their maximum capabilities today. Moreover, the expected air-traffic management (ATM) paradigm shifts towards less voice and more data communications enabling more strategic planning of flight routes requires additional communication capabilities which are not provided by current aeronautical communication systems. Currently, several European research activities are being undertaken with the goal to develop improved communication technologies for aeronautical communication. These activities comprise ground-based, satellite-based, aircraft-to-aircraft and airport communication for all different application classes, like air-traffic services, airline operational and administrative communication, and aeronautical passenger communication. However, an initiative which aims at the integration of existing and emerging communication technologies into a global network has been missing so far. NEWSKY fills this important gap by conducting upstream research activities focused on a global aeronautical network design. Whereas System Wide Information Management (SWIM) provides a conceptual framework for global information sharing, NEWSKY is a technical enabler for the implementation of such an approach. The NEWSKY project does not work on the design new data links. Rather, NEWSKY focuses on the network and transport layer of the protocol stack and pursues the vision of Networking the Sky by integrating a range of data links based on different communication technologies (ground based, satellite-based, aircraft-to-aircraft) as well as different application classes into a seamless network. These applications classes comprise: Air Traffic Services (ATS), Airline Operation Communications (AOC), Airline Administrative Correspondence (AAC), and Aeronautical Passenger Communications (APC). With regards to the evolution of the aeronautical network where IP is being considered as a possible solution, the use of the Internet Protocol (IP) will be investigated in particular. Cost savings, high reliability and an optimal alignment with the evolution of communication and security technologies is intended by using Commercial-Off-The-Shelf (COTS) solutions. Therefore, NEWSKY is involved both in IETF (Internet Engineering Task Force) and AEEC (Airlines Electronic Engineering Committee) ICAO (International Civil Aviation Organisation) activities, in particular in the definition of the Aeronautical Telecommunication Network based on the Internet Protocol Suite (ATN/IPS) in WG-I. Only IPv6 option is considered within the project. Therefore, the NEWSKY project will consider transition issues from the current Aeronautical Telecommunication Network based on OSI technologies (ATN/OSI) and IPv4 networks towards the NEWSKY IPv6- based network. NEWSKY is targeting 2020 for operation of the integrated system, with IP networking capabilities of the ATN/IPS being implemented earlier. Specification of the End-To-End ATM Network Simulator Page: 2-1

23 NEWSKY activities are coordinated with SESAR to ensure the alignment and consistency. The innovative networking approach of NEWSKY enables improved communication capabilities supporting the realisation of SESAR Concepts of Operations. 2.2 Scope of the Document This document is the deliverable D19 Specification of the ATM End-To-End Simulator of the NEWSKY project and is the output of WP4.3 End-to-End ATM Network Simulator. In WP4, the development of the test-bed and the software simulators for the evaluation of the NEWSKY system are carried out. The overall study logic of WP4 is depicted in Figure 2-1. The present document addresses the end-to-end simulations. Figure 2-1: General outline of NEWSKY evaluation process. Deliverable D01.5 has first described the general NEWSKY validation strategy based on the E-OCVM methodology. Table 2-1 to Table 2-6 of D01.5 provide a detailed mapping of the stepped E-OCVM approach to the NEWSKY activities. WP4.1 Simulation Scenarios and Test-Bed Definition proceeded with the next E-OCVM steps and derived indicators and metrics as well as validation scenarios for the simulations in D16 [1]. Based on the scenarios of WP4.1 and appropriate air traffic models the link layer network topology is determined in WP4.2. This is discussed in detail in [6]. The generated network topologies provide the simulation environment for the assessment and evaluation of the concepts defined in WP 2 and WP 3 within WP4.3 Endto-End ATM Network Simulator. The objective of WP4.3 is to simulate the functionality of the NEWSKY network under a realistic load of aeronautical communication applications. Finally WP 4.4 Results Assessment and Recommendations has the objective to assess the gained results against the scenarios and objectives defined in [17] which were derived from the requirements in [31]. Specification of the End-To-End ATM Network Simulator Page: 2-2

24 The objective of WP 4.3 is to simulate the functionality of the NEWSKY network on the basis of the topologies and scenarios created in WP 4.1 and WP 4.2. The simulated ATM, AOC and APC applications are based on the output of WP 4.1 and [4]. The simulated NEWSKY protocol stack is defined in WP 3 and its sub-work-packages ( Efficient Resource Management, Advanced Routing Algorithms, and Seamless Handover Strategies, Security Concept ). In accordance with WP 3.1 suitable resource sharing concepts are identified and implemented. In a similar procedure, suitable routing algorithms as specified in WP 3.2 are tested and evaluated. In addition, appropriate seamless handover strategies (WP 3.3) to support the faultless operation of ATM applications, with their stringent requirements, are validated. All of them are in-line with the security concept defined in WP 3.4. The remainder of this document is structured as follows: Section 3 describes the network load model. It discusses the simulated aeronautical data link applications used to evaluate the network performance. Section 4 presents the network functionality model. That is, it provides an overview of the implemented NEWSKY protocol stack. Detailed specification of the protocols can be found in Appendix B. Section 5 provides a detailed description of the implementation of the end-to-end simulations. In addition, it points out key observations gained during the simulation campaign. These observations are further interpreted and analyzed in section Guidance to Documentation Due to the fact that the development of the NEWSKY simulation environment was conducted in several sub-work-packages the documentation is also dispersed over several documents. Table 2-1 and Specification of the End-To-End ATM Network Simulator Page: 2-3

25 Table 2-2 below provide guidance to relevant project documentation. Note: Deliverable D20 provides an overview of the complete simulation environment. The reports D16, D18, and D19 describe the details of the implementation. Table 2-1: Guidance to documentation Overview. Reference Overview of air traffic simulation D20 section Overview of link model and network topology D20 section Overview of simulation parameters D20 section Overview of data traffic simulation D20 section Overview of simulation scenarios D20 section Specification of the End-To-End ATM Network Simulator Page: 2-4

26 Table 2-2: Guidance to documentation Detailed descriptions. Reference Simulation scenarios D16 section 6 Air traffic simulation D16 section 5.1 D18 section 4 Data Link model D16 section 5.3 D18 section 5 Network topology D16 section 5.4 D18 section 6 D19 appendix A Data traffic simulation D16 section 5.2 D19 section 3 D19 appendix C D19 appendix D D19 appendix E D19 appendix F Protocol implementation D19 section 4 D19 appendix B Handover Framework D14 section Simulation Scenarios The simulation scenarios are described in detail in the references given above. Table 2-3 provides a quick overview for reference. In the last column Network load model the Constant Bit Rate figures (CBR_x/y/z) are shown: x gives the offered load per stream in kbps, y gives the packet size in octets, and z the number of CBR streams. For a detailed explanation refer to D16 section 6 or D20 section 6.5. Deviations from the scenarios defined in D16 are justified in Appendix A on page 9-1. Specification of the End-To-End ATM Network Simulator Page: 2-5

27 Table 2-3: Simulation scenarios. Scenario Reference Scenario Description Air traffic model Network Functionality Model MIP PMIP HAHA MIH LM TCP UDP TM Network load model SIM_01 Node based mobility N X X CBR_0.5/256/4 CBR_0.5/512/4 SIM_02 Node based mobility with make before break handover N X X X CBR_0.5/256/4 CBR_0.5/512/4 SIM_04 SIM_05 Combination of node based mobility and network based mobility Combination of node based mobility and network based mobility with make before break handover N X X X CBR_0.5/256/4 CBR_0.5/512/4 N X X X X CBR_0.5/256/4 CBR_0.5/512/4 SIM_06 Node based mobility with route optimization N, N(USA and Japan A/C) X X X CBR_0.5/256/4 CBR_0.5/512/4 SIM_07 Traffic management reference, dual routers (link capacity 3.5 kbps) C X X CBR_0.25/256/ 8 CBR_0.25/512/ 8 SIM_08 Traffic management, dual routers (link capacity 3.5 kbps) C X X Prio rity CBR_0.25/256/ 8 CBR_0.25/512/ 8 SIM_11 Link assignment reference C 400x400 (20 A/C) X X ATS, AOC, AAC, APC SIM_12 SIM_15 Link assignment, Load balancing (scenarios merged) C 400x400 (20 A/C) X Dynamic X ATS, AOC, AAC, APC SIM_13 Transport layer adaptation reference T X X ATS, AOC, AAC, APC Specification of the End-To-End ATM Network Simulator Page: 2-6

28 SIM_14 Transport layer adaptation T X Enhanced ATS, AOC, AAC, APC SIM_16 Redundancy 1 C 400x400 X X ATS, AOC, AAC, APC SIM_17 Global performance assessment N X Enhanced Prio rity ATS, AOC, AAC, APC 1 The redundancy scenario uses a smaller version of the continental model that was reduced to 200 x 200 nautical miles. In the first second of the scenario no terrestrial links are present. Specification of the End-To-End ATM Network Simulator Page: 2-7

29 3 Network Load Model The data traffic to be conveyed by the NEWSKY network is simulated according to a network load model. This section 3 describes the characteristics of the application layer traffic and the approach to its generation. The NEWSKY network is expected to integrate different types of services. Both safety related services such as Air Traffic Services (ATS) and Airline Operational Communications (AOC), as well as non safety related services such as Airline Administrative Communications (AAC) and Aeronautical Passenger Communications (APC) are considered in NEWSKY. All of these services have significantly different characteristics with regard to the mechanism by which they are triggered, the amount of traffic that they generate, and their QoS requirements. 3.1 ATS Traffic Model The ATS Traffic Model is either based on a simulated data traffic pattern based on the COCR traffic model. In COCR [4], ATS and AOC services are defined for two different phases, targeting different timeframes. Phase 1 is a transition phase in which voice still supports all services, especially when time is critical. Phase 2 is oriented further into the future, where data will have replaced voice in most cases. For the NEWSKY simulations, we will only consider the COCR Phase 2, which is expected to begin around the year Of the services defined in COCR, we retain here only addressed services. Broadcast services are not taken into account, since these services are single hop communications and may not use the IP protocol suite. In addition, some broadcast services such as the surveillance application SURV may make use of a separate link technology. The addressed Phase 2 ATS services are summarized in Table 3-1 below. For a description of the purpose of each of these services, please refer to COCR. Table 3-1: COCR ATS data link services. Service Full Name AC Type ACL ATC Clearance I, II ACM ATC Communication Management I, II A-EXEC Automatic Execution II AIRSEP Air-to-Air Self-Separation II ARMAND Arrival Manager Information Delivery I C&P ACL Crossing and Passing I COTRAC Common Trajectory Coordination II D-ALERT Data Link Alert I, II D-ATIS Data Link Automatic Terminal Information Service I, II DCL Departure Clearance I D-FLUP Data Link Flight Upgrade I, II DLL Data Link Logon I, II D-ORIS Data Link Operational En Route Information Service I, II D-OTIS Data Link Operational Terminal Information I, II Specification of the End-To-End ATM Network Simulator Page: 3-1

30 Service D-RVR Data Link Runway Visual Range I, II DSC Downstream Clearance I D-SIG Data Link Surface Information and Guidance I, II D-SIGMET Data Link Significant Meteorological Information I, II D-TAXI Data Link Taxi Clearance I, II DYNAV Dynamic Route Availability II FLIPCY Flight Plan Consistency I FLIPINT Flight Plan Intent I, II ITP ACL In-Trail Procedure I M&S ACL Merging and Spacing I PAIRAPP ACL Paired Approach II PPD Pilot Preferences Downlink I, II SAP System Access Parameters I URCO Urgent Contact II The column AC Type specifies what type of aircraft makes use of a service. Type I aircraft have only basic data link capabilities and only use a limited number of services, whereas Type II aircraft are fully equipped and use more demanding applications. Some services exist in both an addressed and a broadcast version, such as C&P ACL (addressed) and C&P SURV (broadcast), of which only the addressed version is retained here. The frequency of occurrence of the services is typically defined as a certain number of instances per aircraft per domain. The traffic generated by each of these services is characterized in terms of the number of messages that is generated by an instance of a service, divided into uplink and downlink messages, as well as the size of each of these messages. For the exact number of service instances and the message quantities and sizes, please refer to Appendix C and D. The implementation of the COCR ATS data traffic model is described in Appendix C and D. 3.2 AOC Traffic Model In COCR, AOC applications are defined in the same manner as ATS applications. However, there is not distinction between different aircraft types for AOC. An overview of the AOC applications defined as well as their requirements is given in COCR [4]. All of the AOC services defined in COCR are addressed services. The service instances and message quantities and sizes are defined in COCR as for ATS services. Specification of the End-To-End ATM Network Simulator Page: 3-2

31 Table 3-2: COCR AOC data link services. Service AOCDLL CABINLOG ENGINE FLTLOG FLTPLAN FLTSTAT FREETXT FUEL GATES LOADSHT MAINTPR NOTAMs OOOI POSRPT MAINTRT SWLOAD TECHLOG UPLIB WXGRAPH WXRT WXTEXT Full Name AOC Logon Cabin Log Book Transfer Engine Performance Reports Flight Log Transfer Flight Plan Request Flight Status Free Text Fuel Status Gate/Connecting Flight Status Load Sheet Request Maintenance Troubleshooting Notice to Airmen OOOI Position Report Real Time Maintenance Software Loading Technical Log Book Update Electronic Library Update Graphical Weather Real Time Weather Weather Request For the exact number of service instances and the message quantities and sizes, please refer to Appendix C and E. The implementation of the COCR AOC data traffic model is described in Appendix C and E. 3.3 NET Traffic Model In addition to the ATS and AOC services defined above, COCR also defines two network management services. These allow a host to connect to and maintain the connection to the network. Hence, they are prerequisites for ATS and AOC services to be used. COCR does not assign performance requirements to the network management services. However, since no other communication can take place without these services, it is specified that they shall be treated with a higher priority than all other (ATS, AOC) services. Table 3-3: COCR NET data link services. Service Full Name NETCON Net Connect NETKEEP Net Keep Alive The implementation of the COCR NET data traffic model is described in Appendix C and F. Specification of the End-To-End ATM Network Simulator Page: 3-3

32 3.4 AAC Traffic Model Airline Administrative Communications (AAC) are data services used by the airlines that are not relevant for the safety of the flight. As such, AAC applications are not standardized, making a detailed characterization as for ATS and AOC traffic in the previous sections difficult. Due to regulatory constraints, AAC may not make use of the same spectrum as ATS or AOC. Due to this constraint, as well as the lack of an appropriate data link so far, few AAC applications have been defined. However, [8] provides a list of current and possible future AAC applications. These are characterized according to their message size and the number of messages generated by this service per flight. The description of current AAC applications in [8] is reproduced below in Table 3-4, the description of future applications in Table 3-5. Message Size [Bytes] Messages per flight Applications Crew and AC schedule Quality monitoring 50 2 Service messages Table 3-4: Current AAC Applications Applications Message Size [Bytes] Messages per flight Passenger lists AC catering Baggage handling Lost and Found In-flight assistance Duty free sales Passenger surveys Table 3-5: Future AAC Applications Unfortunately, [8] does not define the exact sequence of messages for each of these services. Whether a service is initiated by the aircraft or by the correspondent node, and how or if the other node responds, is not stated. However, looking at the services in Table 3-4 and Table 3-5, it appears safe to assume that all services are initiated by the aircraft for the purpose of transferring some kind of data to the ground. Because the data that is sent by the AAC applications must be sent in a reliable manner, TCP is assumed as the transport layer protocol. The only responses from the correspondent node on the ground are the TCP acknowledgements. Specification of the End-To-End ATM Network Simulator Page: 3-4

33 3.5 APC Traffic Model In D16 Simulation Scenarios for Concept Validation [16], three types of services are specified that shall be considered for the generation of APC traffic for the simulations in WP 4: http, , and VoIP. Each of these services is to be characterized according to its arrival rate, service time, and data rate. Instead of providing only the mean data rate for each instance of a service, we go one step further and define the rate at which packets are generated and the distribution of the size of these packets. Since this traffic is specified on a per user basis, it must be further aggregated to obtain the amount of traffic that is generated by an aircraft. As this should not affect the properties of a single traffic flow, the arrival rate of each of the three services must be scaled according to the number of users onboard the aircraft. 2 If the number of passengers (or seats) on board each flight is not known in the simulations, a typical aircraft configuration can be assumed. Based on the seat plans of the Lufthansa fleet, 200 seats are assumed, of which 4 are first class, 36 are business class, and 160 are economy class. Of course, not all passengers will make use of APC services. The probabilities of use [16] are given below in Table 3-6. Note that, compared to D16, the probability of VoIP use by an economy class passenger has been reduced from 0.5 to Services / Users Economy business first VoIP http Table 3-6: Probabilities of service use by passengers Together with the typical aircraft configuration, this results in 64 VoIP users, 48 http users, and 44 users per flight. The characterization of each of these services is given in the following sections. Temporal variations of a user s traffic profile, e.g. according to the day time, are not taken into account. However, it should be taken into account that APC services will likely be deactivated during the take-off and landing phases of a flight. Correlations between different services, such as a lower likelihood for sending an while performing a VoIP call are not considered. In general, QoS requirements are not formulated for APC traffic. However, empirical values for the acceptable delay of voice connections can be used as reference HTTP Traffic HTTP traffic is characterized by the following components, in decreasing level of granularity. This description and the values for the different parameters are taken from [18]: A Poisson distributed session arrival process. 2 Note: For X and Y independent Poisson distributed random variables with parameters λ and μ, the random variable X+Y also follows a Poisson distribution with parameter λ + μ. Specification of the End-To-End ATM Network Simulator Page: 3-5

34 We propose a session arrival rate of 1/h. However, this value could be adjusted to modify the weighting of the amount http traffic with respect to the other two service types. The number of page requests per session Geometrically distributed random variable with mean 10 The reading time between page requests Geometrically distributed random variable with mean 206 s The number of packets per page request Geometrically distributed random variable with mean 250 The packet size Pareto distributed with cut-off to limit the maximum packet size to 66,666 bytes, where the mean value is 480 bytes and the minimum is 81.5 bytes. The pdf of the Pareto distribution is characterized by the shape parameter α = 1.1 and the scale parameter k = The scale parameter also defines the minimum packet size. The above parameters lead to a mean page size of 120 kbyte. Return traffic from the user onboard the aircraft to the APC correspondent node on the ground is simply modelled as a response to the forward traffic. Each forward packet triggers a packet of size 40 byte that is sent from the mobile host to the correspondent node. This results has an asymmetry of ca. 1:10 between the forward and return paths, which is well in line with observations of traffic traces from the Internet. HTTP uses TCP as its transport layer protocol Traffic For the modelling of traffic, we distinguish between messages that are sent (e.g. via SMTP) and messages that are retrieved from the server (e.g. via POP3 or IMAP). For messages that are sent by the mobile host, we assume that messages are generated according to a Poisson process with mean λ = / min [23]. For received messages, we assume a Poisson process with mean λ = / min. This difference in generation rates accounts for the fact that s are often sent to more than one recipient. In both cases, the message size is composed of a constant 300 bytes plus an additional number of byte according to a log-normal distribution with mean and variance 3.1. This results in a mean message size of 60 byte, as reported by [22]. This number is derived from the analysis of traffic traces in the Internet. Both SMTP and POP3/IMAP use TCP as their transport layer protocol VoIP Traffic For VoIP calls, we assume that each user generates calls according to a Poisson process with mean arrival rate λ = 0.5 / h. These calls are served according to negative exponentially distributed call holding time. To account for periods of activity and silence during a call, the voice conversational model of [20] is used, assuming a voice activity of The G (5.3 kbps) audio codec inserts two 20 byte frames of 30ms duration each in one IP packet when the encoder is active, and two 4 byte frames when the encoder is silent. That is, every 60 ms, an IP packet with payload size of either 40 bytes Specification of the End-To-End ATM Network Simulator Page: 3-6

35 or 8 bytes is generated. Considering a voice activity of 0.43, this codec provides an average data rate of 2.89 kbps. For the exponentially distributed call holding time τ, we adopt τ = 1 / μ = 6 min as given in [24] for business calls. VoIP clients use UDP as their transport layer protocol. Since VoIP is a bidirectional service, it is assumed that the same traffic is also generated on the reverse path. The ITU recommendation ITU-T G.114 [25] provides information on the delay that can be tolerated for a voice connection. According to this model, users begin to become dissatisfied when the one-way end to end delay exceeds roughly 300 ms. 3.6 Constant Bit Rate Traffic The COCR, AAC and APC data traffic pattern do not produce data traffic all the time. Between short times of activity there are large gaps of silence. This poses a problem if the reaction of the network to infrequent events (e.g. handovers) shall be measured, because there is the high probability of a traffic gap during the event. In order to gain more measurements in these cases several simulation scenarios use constant bit rate traffic with short packet inter-arrival times (i.e. less than a second in the simulations). The constant bit rate traffic generator works on the basis of an exponential distribution. Thereby, the mean value is derived by the parameters of "packet size" and "data generation rate". This means that the constant bit rate generator produces packets of the same size in random intervals based on an exponential distribution with a mean of data rate divided by packet size. Different simulation scenarios use different CBR parameters. These parameters are displayed in Table 2-3. Specification of the End-To-End ATM Network Simulator Page: 3-7

36 4 Network Functionality Model In the following a short summary of the protocol descriptions is presented that provides an overview to which extend the protocols have been implemented. The full specifications can be found in Appendix B Detailed Protocol Descriptions. 4.1 Overview Table 4-1 shows a list of protocols/algorithms that have been selected in WP3 and lists whether they are also implemented/used within the simulations. Protocol / Algorithm RFC 4861 (Neighbor Discovery) RFC 4862 (Stateless Autoconfiguration) RFC 3774 (MIPv6) RFC 3963 (NEMO Basic Support) RFC 5213 (Proxy Mobile IPv6) RFC1331 (PPP) draft-thubert-mext-global-haha- 00 (Global HAHA) draft-wakikawa-mip6-nemohaha-01 (Inter Home Agents Protocol) Correspondent Router (RO protocol) MIRON (RO protocol) draft-ietf-monami6-mipv6- analysis-05 (Multihoming) Basic IEEE primitives IEEE Information Service IEEE based networkinitiated Handovers IEEE IE_Network primitive Dynamic Link Selection Conservative Link Selection (with and without simplified multihoming) Protocol/Algorithm implemented for simulations Specification of the End-To-End ATM Network Simulator Page: 4-1

37 TCP adaptations Performance Enhancing Proxies Priority scheduling mechanisms IKEv2 / IPsec DiffServ architecture + Mapping Table 4-1: List of NEWSKY specified protocols implemented for simulations. The following table provides a mapping of which specific protocols and algorithms are used in every individual simulation scenario. The scenarios are defined in [17]: Reference Related Standards & Algorithms SIM_01 RFC 3963 SIM_02 RFC 3963 IEEE SIM_04 RFC 3963 RFC 5213 SIM_05 RFC 3963 RFC 5213 IEEE SIM_06 RFC 3963 draft-thubert-mext-global-haha-00 draft-wakikawa-mip6-nemo-haha-01 SIM_07 RFC 3963 SIM_08 RFC 3963 SIM_13 RFC 3963 SIM_14 RFC 3963 TCP adaptations SIM_16 Dynamic Link Selection algorithm IEEE SIM_17 RFC 3963 RFC 5213 draft-thubert-mext-global-haha-00 draft-wakikawa-mip6-nemo-haha-01 IEEE Dynamic Link Selection TCP adaptations Table 4-2: Mapping of simulation scenarios to protocols/algorithms. Specification of the End-To-End ATM Network Simulator Page: 4-2

38 4.2 Network Topology The network topology model is the same in all scenarios. The access link and access network model used for the simulations is a simplified model considering only key performance characteristics of the access links and their access networks. It is designed to capture only the aspects of the network behaviour relevant to layer 3 and above. A detailed description of the network topology can be found in [29]. A diagram of the network topology is displayed in Figure 4-1 for reference. Figure 4-1: Overview of network topology. Specification of the End-To-End ATM Network Simulator Page: 4-3

39 4.3 Resource Management Concepts The general QoS architecture determines the way priorities are handled and which possibilities and means are given to control the allocation of resources to entities, flows or packets. The details of the implementation with respect to the resource management concepts are the following: The overall QoS management architecture is based on DiffServ, i.e. resources are managed per traffic aggregate. The set of Classes of Service (CoS) for operational communication (ATC and AOC), as defined in the COCR consists of 12 CoS (DG-A DG-L). In line with the outcomes of [28], these 12 CoS are mapped in to 6 DiffServ traffic aggregates according to Table 4-3. INET traffic services (i.e. AAC and APC) have been categorized into CoS service classes as well (i.e. DG-C, DG-H, DG-K, and DG-M). Note DG-M has been added for INET services, i.e. APC. For details see [28]. Signalling Traffic DG-A DG-B DG-C DG-D DG-E DG-F DG-G DG-H DG-I DG-J DG-K DG-L DG-M Default EF AF3 AF4 AF3 AF2 AF1 BE Table 4-3: Mapping of CoS to DiffServ aggregates Scheduling Since the traffic management in DiffServ is made on a per-packet basis (i.e. dependent on the aggregate that the packet belongs to), scheduling algorithms have to be applied in order to provide the required packet prioritization. In line with the investigation in D12 [28], the different scheduling mechanisms are applied for operational and non-operational traffic For operational traffic (ATC/AOC), it is assumed that each output link has a DiffServ scheduler Among the different classes of Service (CoS) a strict priority scheduler is implemented which always give precedence to packets with a higher DiffServ Code Point (DSCP) (AF4 is treated preferred to AF3, etc.) Specification of the End-To-End ATM Network Simulator Page: 4-4

40 Within the datagrams of a DiffServ aggregate, a fair scheduling is applied by a simple Round Robin scheduler. For non-operational AAC and APC communication, a fair scheduler is used among the different users, i.e. among the passengers for APC to share the bandwidth equally. Within the simulations performed here a simple round robin scheduler is implemented for this purpose and in order to keep the simulation complexity reasonable. For each passengers APC traffic (each ES AAC traffic respectively), a prioritization scheduling algorithm is used. Within the simulations performed here, a strict priority scheduler is applied for keeping the simulation complexity reasonable Link Selection For the link selection the algorithm as recommended in D12 [28] is implemented. The purpose of this algorithm is to select a suitable link for the communication among the available links. As a baseline algorithm for the reference scenario, the simple link selection is implemented (see Annex B) which makes only use of basic link information (link up, link down) as is available from legacy equipment. For simulation scenarios SIM_01 and SIM_02, no multihoming is used. In this case, the link selection is triggered in case of a Link down event (SIM_01) or a change of the flight phase, and in case of a Link going down event (SIM_02) or a change of the flight phase. For the more sophisticated link selection scenario (SIM_12), a dynamic link selection algorithm as specified in annex B is implemented. This algorithm takes more sophisticated link information as provided by into account such as delay, throughput, and SNR. In the frame of the simulation scenarios SIM_11 and SIM_12, the implementation of the multihoming protocol is abstracted and simplified in the following way: The mobile router (MR) as well as the Home Agent (HA) both keep a list with all configured and registered IP addresses (1 IP address per link). As soon as a link is detected available, layer 2 connectivity is established automatically and the IP address is configured and registered. The HA and the MR add this new IP address then to their list of registered IP addresses. The signalling for the registration is abstracted here, i.e. no real datagrams are exchanged but the registration is done internally to the simulator. The information about the link status, i.e. delay, available throughput and SNR are signalled to the MR and the HA. The signalling via the IE_network primitive is hereby abstracted to providing the information simulation internally. The link decision mechanism is implemented in the MR and the HA as specified in annex B. Dependent on the decision of the link selector, the source destination IP address is set in the packet and the packet is sent over the corresponding link Transport Layer The Transport Layer is either realized through a User Datagram Protocol (UDP) for unreliable data transmissions or through the Transmission Control Protocol (TCP) for reliable data transmissions. Specification of the End-To-End ATM Network Simulator Page: 4-5

41 TCP has many flavours. In this case it was implemented as defined in RFC753, RFC2001, and RFC3465. The improvement in order to speed up TCP for aeronautical communication services suggested by D12 was to apply window scaling and to increase the initial congestion window. The window scale parameter was set to 11 (meaning that both TCP sender and receiver implement window scaling option if this is the case). This improvement was only used in scenario SIM_14 and SIM_ Advanced Routing Concepts Neighbor Discovery Neighbor Discovery is used by IPv6 nodes on the same link to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. The implementation details are as follows: Neighbor Solicitations are sent to request the link-layer address of a target node while also providing the senders own link-layer address to the target. Neighbor Advertisement messages are sent in response to Neighbor Solicitation messages. Neighbor Solicitation, Neighbor Advertisement, Router Solicitation and Router Advertisement messages always include the source link-layer address option. Neighbor Advertisement messages always include the target link-layer address option. The Prefix information option always contains exactly one prefix with length 64 bits and on-link & autonomous address-configuration flag set to 1. Every link has exactly one access router. Hence, only one default router per link/subnet is possible. The Neighbor Cache has a reduced set of states (see Appendix B Detailed Protocol Descriptions ) Joining the solicited-node multicast address is not implemented, but emulated by an artificial delay. In the absence of any default router, packets are queued until a new default router has been detected Stateless Autoconfiguration Stateless Autoconfiguration defines the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection (DAD) procedure to verify the uniqueness of the addresses on a link. The protocol has been significantly simplified: It is assumed that routers are preconfigured with valid global addresses Specification of the End-To-End ATM Network Simulator Page: 4-6

42 Address lifetimes have been omitted (infinite lifetime is assumed) Every interface has one link-local and one global address. After movement has occurred, both addresses are validated While DAD is in progress, packets that are not ND messages are discarded. The Neighbor Solicitation and multicast listener discovery message(s) during DAD are not implemented; the delay caused by them is taken into account though Mobility Support in IPv6 (MIPv6) MIPv6 is a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. Mobile IPv6 is a comprehensive protocol, but for the purpose of the simulations it was significantly reduced to its core functionalities: IPsec for protecting mobility signalling or payload traffic is not implemented Mobile Node (MN) and Home Agent (HA) use bi-directional tunnelling for traffic forwarding Route Optimization between MNs and Correspondent Nodes (CNs) is not implemented HAs act as border router; Proxy Neighbor Discovery is therefore not necessary. Binding Registrations at the HAs always succeed (no lack of resources, etc.), except for protocol related errors (wrong sequence number, etc.) The Advertisement Interval Option in the RAs provides MNs with an indication on the frequency of RAs Access routers periodically send RAs in an interval larger than originally specified in the MIPv6 RFC (MinRtrAdvInterval/MaxRtrAdvInterval). The DAD procedure at the HA is implemented as delay only (similar to DAD at the MN). Movement Detection: a number of three missed Router Advertisements is regarded as indication that the default router of the associated link/subnet is not available anymore Network Mobility (NEMO) The Network Mobility (NEMO) Basic Support protocol enables Mobile Networks to attach to different points in the Internet; it is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router (MR), which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. The differences between MIPv6 and NEMO are only minimal: Specification of the End-To-End ATM Network Simulator Page: 4-7

43 The BU (per MN) contains two MNP options The behaviour of the end systems attached to the Mobile Router can be emulated: applications reside within the protocol stack of the MR Global HA to HA The Global HA to HA protocol provides some extent of route optimization support for NEMO. The starting point of its development was the observation that the binding of the MR to a single fixed HA, regardless of its relative location, is in general not a satisfactory solution. With regard to the network performance the sub-optimal routing path of MRs in great distance from their HAs causes unnecessarily high latencies on the end-to-end path. Consequently, the solution envisaged by Global HA-to-HA relies on a distributed HA architecture that allows the MR to bind with its topologically closest HA. The most important aspects of the protocol are summarized below: The Extended Home Network consists of several Home Agents The Home Agents are fully meshed with each other by means of bidirectional tunnels Mobile Nodes/Routers have a binding with not more than one Home Agent at a certain point in time. Every MN/MR is topologically anchored at one HA (the primary HA). Dynamic Home Agent Address Discovery (DHAAD) is used to retrieve the address of the closest Home Agent. HAs use proactive synchronization: after processing a BU from a MN/MR, the HA shared its binding information with all other HAs to enable proper routing within the Extended Home Network Proxy Mobile IPv6 (PMIPv6) Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signalling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signalling on its behalf. The protocol details are as follows: Local Mobility Anchors (LMAs) create prefix routes to the MAGs (Mobile Access Gateways) for the MNs or MRs as /128 or /64 routes. Proxy Binding Updates and Acknowledgements are synchronized based on timestamps. Tunnels between LMAs and MAGs are pre-established. The link-layer identifier(s) is equal to the MAC address of the interface(s) of the MN. Every MAG has only one LMA The MN policy profile is implemented as a global database accessible by all simulation entities that require access to it. Specification of the End-To-End ATM Network Simulator Page: 4-8

44 MN-Identifiers are globally unique. The MN-Identifier should be provided by either a dedicated layer 2 exchange or at least prior to any other Neighbor Discovery or IP specific exchanges. The MAG ignores all Router Solicitations until the PBA was received. Upon reception of the PBA, the MAG automatically sends a Router Advertisement to the MN. For foreign networks operating with PMIPv6, the MAGs will not advertise the home network prefix of the MN, but instead a care-of prefix that is stable across this very PMIPv6 domain. A mobile node will use this care-of prefix to configure it s care-of address that will be registered with the MNs Home Agent, following standard Mobile IPv6 behaviour. If a MN moves to a new MAG of the same PMIPv6 domain and that MAG registers with the LMA, the LMA can send a notification to the old MAG that triggers the resource cleanup. 4.5 Seamless Handover Strategies Media Independent Handover Function The aim of the IEEE standard is to provide link layer intelligence and network information to upper layers (layer 3+) in order to facilitate handovers between different access networks, especially between those which are based on different link technologies. The primitives that have been selected in [16], from Event and Command Service only, are as follows: Basic MIHF interfaces to the lower and higher layers: MIH_LINK_SAP and MIH_SAP MIH_Link_Going_Down MIH_Link_Down MIH_Link_Up MIH_Link_Detected MIH_Link_Actions Specification of the End-To-End ATM Network Simulator Page: 4-9

45 5 Simulation Software Design and Integration The NEWSKY evaluation environment models the simulation scenarios defined in [17]. The challenges raised by modelling these complex and dynamic scenarios have been decomposed into several mutually depended simulation services. Each service is implemented as one of three individual simulation modules: A mobility model, a topology model, and an end-to-end model. The mobility module 3 is the starting point for all evaluation scenarios. It provides a model for the physical properties of the aeronautical environment by defining the locations and movement patterns of all mobile NEWSKY nodes (e.g. ground-stations, aircraft, Unmanned Aerial Vehicles (UAVs), satellites, etc.). It provides the position, heading and altitude of each single aircraft during the complete simulation time. This is crucial as these values provide the necessary information to derive the available data links (within the topology module) and influence the behaviour of several communication applications (within the data module; e.g. COCR message generation according to the flight phase). The mobility model is discussed in [29] section 3. The topology model represents the underlying sub-network technologies by their link layer topology and their link layer characteristics. Given the technical scope of NEWSKY, both, nodes and communication cells, may move, which makes the effective link layer network topology a (time dependent) function of the applied mobility model. Additionally, the data link characteristics (e.g. delay, throughput, etc.) may change according to the current node position, too. This module is discussed in detail in [29] section 4 and 5. The third module of the evaluation environment is the end-to-end model, which includes the network architecture (i.e. protocol stack) and application data generation (i.e. generation of the network load). Assuming that future aeronautical communication applications will be position related in many cases, there is a clear dependency of the network load generation on the link layer topology and a possible impact on the mobility model (e.g. through COCR message generation according to the flight phase). The endto-end module is described in this document. One particular property of the simulated environment is the mutual dependency of node mobility, network topology and load generation. The mobility model defines the movement of aircraft and communication cells. After each movement update the link level network topology and its characteristics are recalculated to reflect the new situation. Based upon this topology information (which includes the actual position of an aircraft) data communication is carried out. During the complete simulation process statistical data is gathered by an additional and independent statistics module. This section does not only describe the software design and integration, but provides also first observations on the results. A detailed analysis of the results can be found in [30]. 3 The implementation of a particular simulation service is referred to as module. We will use the terms model, service and module as synonyms here. Specification of the End-To-End ATM Network Simulator Page: 5-1

46 5.1 NEWSKY end-to-end simulation model In the following the simulation model of the NEWSKY end-to-end network simulator is explained in a simple fashion. This shall help to get a high level view of the simulation environment. First we give an overview of the procedural chain of activities during a simulation run, which is followed by a more detailed explanation of each step. Then we discuss the various configurations of the single simulation runs. 1st step - read configuration file 2nd step - initialize parser and start to read topology input file 3rd step - instantiate all simulation entities (i.e. net nodes and net links) 4th step - load protocol modules (e.g. IPv6, MIPv6, etc.) onto protocol stack of net individual net nodes 5th step - continuous processing during simulation run o update topology accordingly to input file (i.e. link changes, aircraft position updates, etc.) o generate data (e.g. COCR traffic pattern, or CBR) and transmit it via the network o log simulation events 6th step - evaluate produced data The first step (reading the configuration file) makes sure that simulation parameters are loaded properly according to the wished simulation scenario. As agreed upon in an earlier project phase the NEWSKY end-to-end topology simulator shall be capable of different simulation scenarios (i.e. different network-link interfaces, network protocols, and transport protocols). Different simulation scenarios are set up through configuration files. Later on these configuration files are explained in more detail (cf. Section ). The second step (initializing the parser and initializing the topology) guarantees that the input file is read properly. The input file is generated by the NEWSKY topology simulator. This file contains all necessary data for the NEWSKY end-to-end simulator. This comprises information about the simulation entities (i.e. net nodes and net links), aircraft, COCR data generation information, and link properties (this also includes MIH information). Figure 5-1 shows a graphical representation of the topology input file where for instance a mobile router (onboard an aircraft) is connected with two clients (i.e. ATS and AOC) via an onboard LAN. This mobile router has communication capabilities via wireless links towards the ground (i.e. link4 and link6). The third step (instantiation of simulation entities) ensures that all simulation entities are instantiated (i.e. the software creates an object) and stored centrally. In such a way simulation entities are easier manageable in terms of software. Simulation entities comprise net nodes and net links, where a net node can have one of many different types (e.g. ats client, ats server, mobile router, home agent, etc.) and may belong either to the ATN or to the INET network. Similarly, a net link can be one of many different types (e.g. link3, link4, infrastructure network, onboard LAN, etc.) and may belong either to the ATN or to the INET network. Additionally, the net links have different properties like mean access delay, available bandwidth, and if applicable signal to noise ratio. The Specification of the End-To-End ATM Network Simulator Page: 5-2

47 simulated aircraft which are flying from departure to arrival port are also stored centrally accessible in the simulation software. According to any simulation update regarding aircraft properties the aircraft parameters are updated (mostly position updates). Note that not only from an architectural point of view, but also from a software point of view, the aircraft is holding several net node objects (i.e. the communication clients and the mobile router). Figure 5-1: Graphical representation of topology data. The fourth step (loading protocol modules, hence the protocol stack) is the most important step for the NEWSKY end-to-end simulator as it is responsible for the dynamic aggregation of software during the runtime of a simulation. This means that dependent on the configured simulation scenario (conducted in step 1), the simulation software loads different protocol stacks on the various net node entities. The protocol stack itself consists of several pieces of software (due to the layered protocol stack), which interact among each other via a commonly defined interface. The interface supports a generic data packet object as parameter which is passed along the protocol stack (either up or down). Dependent on the net node type the proper software pieces are loaded onto the protocol stack. After this step the topology has been loaded and all (right from the beginning) participating entities are instantiated. From now on the NEWSKY end-to-end simulation starts and the simulation time progresses. (The time progress of the simulation depends on the amount of tasks to do. The absolute simulation time varies for this reason and depends also on the simulation scenario.) During the course of the simulation certain topological parameters may change - i.e. wireless link connectivity, communication peers, aircraft position and domain, aircraft entering/leaving the simulation coverage zone, etc. - these have to be updated accordingly. Additionally, data traffic is generated and routed through the network according to the network protocols implemented and described in annex B (each scenario might handle the routing differently). Each event relevant for the simulation scenario evaluation is logged in order to produce statistical data after a simulation run. The final step of the NEWSKY end-to-end simulator is to process the gained data and produce statistical data which are used to analyze the various scenarios and can be seen in the annex of the NEWSKY deliverable D20 where the results are discussed in detail. Specification of the End-To-End ATM Network Simulator Page: 5-3

48 5.2 Simulation Scenario Settings Note that some simulation scenarios that were originally proposed at the beginning of the work-package 4 were later removed. The original numbering scheme was however retained Simulation Scenario High Level Overview Simulation scenario 01 (SIM 01) is the reference scenario in order to evaluate mobility protocols. SIM 01 uses node based mobility, the North-Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. The various protocol stacks of the individual participants of the simulation (i.e. net nodes) look like as depicted in Figure 5-2. The client and server instances are producing data streams dedicated for each other. The network between client and server consists of a mobile router, a home agent, and several routers distributed along the path. As Figure 5-2 shows every net node instantiates IPv6, the communication endpoints (i.e. client and server) instantiate UDP and CBR traffic generators, and Mobile IPv6 (MIPv6) is instantiated by the mobile routers and home agents. Thereby, MIPv6 also includes NEMO capabilities. Note that the bottleneck is the wireless link and the queuing discipline at the mobile router and access router, respectively, has been chosen to be a first come first serve discipline. Furthermore, the link selection algorithm is based on a simple preference based table depicted in Table 5-1. The link properties are defined in [29]. Figure 5-2: Protocol stack visualization of SIM 01. Table 5-1: Preference table for simple link selection. Domain ATN INET APT Link 3, Link 4, Link 6, Link 8 - TMA Link 4, Link 6, Link 8 - ENR Link 4, Link 6, Link 8 Link 5, Link 8, Link 9 ORP Link 6, Link 8 Link 6, Link 9 Specification of the End-To-End ATM Network Simulator Page: 5-4

49 Key Issues of Implementation Actually there are two key points of this scenario. First the Home Agent has to maintain a cache where mobile nodes can enter their current location within the network, further more the Home Agent has to intercept packets destined for its sub-network. If a packet is destined for its sub-network and the corresponding mobile node is away from home it has to look up the cache and if an entry is present tunnel the packet towards the given location. If no entry exists and the mobile node is not at home the packet is lost and accounted as such. The second key point is that the Mobile Router (hosted onboard an aircraft) detects wireless links through Router Advertisements sent by an access router. These detected links shall be maintained by a so called neighbor cache which is more or less responsible for the proper transmission of the packet via the air. The key issue here is that the neighbor cache of the Mobile Router detects and configures new wireless links and if links get inactive first set entries to inactive and finally delete them from the cache. If neighbor cache entries stay active longer than the link is available packets may be lost Configurable Parameters For the simulation of SIM 01 the following values have been used (note that the key parameter settings are discussed in the next sub-chapter): MAX_RA_INTERVAL=2.0 MIN_RA_INTERVAL=1.0 LINK_MONITORING_INTERVAL=2.0 LINK_INCOMPLETE_INTERVAL=6.0 MLD_DELAY=2.0 DAD_DELAY=4.0 BINDING_UPDATE_TIMEOUT=10.0 The maximum interval between consecutive Router Advertisements (value given in seconds). The MIPv6 specification recommends a value of 0.07 seconds, whereas the Neighborhood Discovery protocol determines a value of 5 seconds. The minimum interval between consecutive Router Advertisements (value given in seconds). The MIPv6 specification allows a value as low as 0.03 seconds, where as the Neighborhood Discovery protocol determines a value of 3 seconds. The link monitoring interval is set to the same value of maximum router advertisement interval (value given in seconds). Thereby, new advertisements are definitely captured within one interval. The incomplete interval is set to three times the maximum router advertisement interval (value given in seconds). The Multicast Listener Discovery (MLD) delay (value given in seconds) models the maximum delay until the MLD process has been finished in the simulation (i.e. up to x seconds may be used to finish this configuration process). The Duplicate Address Detection (DAD) delay (value given in seconds) models the maximum delay unit the DAD process has been finished in the simulation (i.e. up to x seconds may be used to finish this configuration process). The Binding Update Timeout (value given in seconds) determines the time interval of a possible re-transmission of a Binding Update if no acknowledgment has been received within this time interval. Specification of the End-To-End ATM Network Simulator Page: 5-5

50 BINDING_UPDATE_RETRIES=3 BINDING_UPDATE_SIZE=112 BINDING_ACK_SIZE=52 The Binding Update retries variable determines the amount of consecutive re-transmission attempts of a Binding Update if no acknowledgment is received. The total size of a Binding Update is set to 112 bytes the message consists of: IPv6 Header (40 byte) Destination Options Header (2 byte) Home Address Destination Option (18 byte) Mobility Header (6 byte) Binding Update (6 byte) Mobile Network Prefix Option (2 times 20 byte) either for ATC and AOC networks or for AAC and APC networks. The total size of a Binding Acknowledgment is set to 52 bytes the message consist of: IPv6 Header (40 byte) Mobility Header (6 byte) Binding Acknowledgment (6 byte) No options RA_SIZE=106 The total size of a Router Advertisement is set to 106 bytes the message consists of: RS_SIZE=58 OVERHEAD_UDP_IPv6=48 IPv6 Header (40 byte) ICMPv6 Header (4 byte) Router Advertisement (12 byte) Option Header (2 byte) Option Source Link Layer Address (8 byte) Option Header (2 byte) Option Prefix Information (30 byte) Option Header (2 byte) Option Advertisement Interval (6 byte) The total size of a Router Solicitation is set to 58 bytes the message consists of: IPv6 (40 byte) ICMPv6 Header (4 byte) Router Solicitation (4 byte) Option Header (2 byte) Option Source Link Layer address (8 byte) The overhead UPD_IPv6 (value given in bytes) indicates the amount of overhead per packet which carries regular UDP data. The amount includes a 8 byte UDP header plus a 40 byte IPv6 Header. Specification of the End-To-End ATM Network Simulator Page: 5-6

51 OVERHEAD_UDP_IPv6_IPv6=88 LINK3_PER_USER_CAPACITY_FL=20 LINK3_PER_USER_CAPACITY_RL=20 LINK4_PER_USER_CAPACITY_FL=20 LINK4_PER_USER_CAPACITY_RL=20 LINK5_PER_USER_CAPACITY_FL=20 LINK5_PER_USER_CAPACITY_RL=20 LINK6_PER_USER_CAPACITY_FL=20 LINK6_PER_USER_CAPACITY_RL=20 LINK8_PER_USER_CAPACITY_FL=20 LINK8_PER_USER_CAPACITY_RL=20 LINK9_PER_USER_CAPACITY_FL=20 LINK9_PER_USER_CAPACITY_RL=20 CBR_KPBS_ATC_FL=0.5 The overhead UPD_IPv6_IPv6 (value given in bytes) indicates the amount of overhead per packet which carries regular UDP data within an IPv6 tunnel. The amount includes a 8 byte UDP header plus two times a 40 byte IPv6 Header. This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 3 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 3 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 4 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 4 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 5 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 5 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 6 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 6 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 8 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 8 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 9 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 9 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of data produced per ATC server (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from ATC server to ATC client (communication peers change during the course of the simulation). Specification of the End-To-End ATM Network Simulator Page: 5-7

52 CBR_KPBS_ATC_RL=0.5 CBR_KPBS_AOC_FL=0.5 CBR_KPBS_AOC_RL=0.5 CBR_KPBS_AAC_FL=0.5 CBR_KPBS_AAC_RL=0.5 CBR_KPBS_APC_FL=0.5 CBR_KPBS_APC_RL=0.5 CBR_PACKETSIZE_ATC_FL=256 CBR_PACKETSIZE_ATC_RL=256 CBR_PACKETSIZE_AOC_FL=256 CBR_PACKETSIZE_AOC_RL=256 CBR_PACKETSIZE_AAC_FL=256 This parameter determines the amount of data produced per ATC client (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from ATC client to ATC server (communication peers change during the course of the simulation). This parameter determines the amount of data produced per AOC server (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from AOC server to AOC client (communication peers change during the course of the simulation). This parameter determines the amount of data produced per AOC client (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from AOC client to AOC server (communication peers change during the course of the simulation). This parameter determines the amount of data produced per AAC server (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from AAC server to AAC client (communication peers change during the course of the simulation). This parameter determines the amount of data produced per AAC client (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from AAC client to AAC server (communication peers change during the course of the simulation). This parameter determines the amount of data produced per APC server (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from APC server to APC client (communication peers change during the course of the simulation). This parameter determines the amount of data produced per APC client (value given in kilobits per second). That is, for each aircraft a data stream of n kilobits is produced from APC client to APC server (communication peers change during the course of the simulation). This parameter determines the produced packet sizes of the constant bit stream between ATC server and ATC client (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between ATC client and ATC server (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between AOC server and AOC client (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between AOC client and AOC server (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between AAC server and AAC client (value given in bytes). Specification of the End-To-End ATM Network Simulator Page: 5-8

53 CBR_PACKETSIZE_AAC_RL=256 CBR_PACKETSIZE_APC_FL=256 CBR_PACKETSIZE_APC_RL=256 This parameter determines the produced packet sizes of the constant bit stream between AAC client and AAC server (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between APC server and APC client (value given in bytes). This parameter determines the produced packet sizes of the constant bit stream between APC client and APC server (value given in bytes) Key Observations of Scenario Table 5-2: Configurable parameters of SIM 01. The Router Advertisement interval has been set higher than recommended by MIPv6. Note that the link monitoring and link incomplete values of the neighbor cache have to be set in accordance to the router advertisement intervals (this is implicitly known through the router advertisement interval option). There are several reasons for this choice. First the produced amount of overhead solely through Router Advertisements sent at an average rate of 0.05 seconds cumulates to roughly 17 Kbps on the Forward Link (FL) almost 10 % of a possible future ATC link. Second, the link switch cannot be accelerated through more Router Advertisements if a handover takes place between identical link types. The assumption is that a link of a certain type can only be active with one connection (i.e. the current link is going down; afterwards a new link of the same type comes up and configures itself this takes a certain amount of time). Therefore, the link auto-configuration has to be taken into account as well. This means that an immediate (not accounting for binding update delay) switch from the previous link to the next link is not possible, except for a switch to a different link technology (e.g. form link-type 3 to link-type 4). Third, a seamless connection is only necessary if streaming data has to be sent (i.e. voice). Therefore, less router advertisements and a larger connectivity gap are tolerable if time insensitive data is sent (that is mostly the case for aeronautical applications). The Mobile IPv6 parameters are displayed in the table above. The link capacity values are selected rather high in order to reflect the network layer capabilities and not the link itself. Note that these values are usually much lower Simulation Scenario High Level Overview Simulation scenario 02 (SIM 02) uses node based mobility with support of the Media Independent Handover framework, the North-Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. SIM 02 differs in comparison to SIM 01 only in one point, namely, that the mobile router implement parts of the Media Independent Handover framework (see Appendix B section 10.1). In the simulation framework this basically means that the mobile router detects link handovers between the same link types faster. Note that only the functionality has been implemented without considering any overhead (as we use only Specification of the End-To-End ATM Network Simulator Page: 5-9

54 the LINK_SAP primitives, which are implemented locally, there is no overhead on the link) Configurable Parameters Figure 5-3: Protocol stack visualization of SIM 02. The taken parameters for this scenario are identical to the one of simulation scenario 01. The only difference is that MIH functions are loaded onto the protocol stack of the mobile router and the access router Key Observations of Scenario Implementing the MIH function does only shorten the time until the mobile router s neighbor cache detects that a certain link is inactive. This means that link handovers between the same link-type are only speed up in such a way that lost link connectivity is detected faster (i.e. the new link needs to run through the auto-configuration process until it can be used). In case inter-technology handovers are performed, the MIH function can support make-before-break strategies and therefore faster handovers - as the expected loss of a link can be detected in advance and another link therefore already be prepared (in terms of IP configuration) Simulation Scenario 03 Removed. See Appendix A Simulation Scenario High Level Overview Simulation scenario 04 (SIM 04) uses network based mobility, the North-Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. The network based mobility is based on the Proxy Mobile IPv6 protocol (PMIPv6), which requires two additional instances within the simulation environment. The access point (or access router) for a mobile router becomes the Mobile Access Gateway (MAG) which takes care of the mobility of a mobile node (or network) within a proxy mobile domain. The Mobile Access Gateway (MAG) does this by communicating location information of mobile routers towards the Local Mobility Anchor (LMA), which also incorporates functionality of a Home Agent. The PMIPv6 concept is originally intended for providing mobility support towards mobile nodes (or networks) within a single domain. Within the simulation environment several Specification of the End-To-End ATM Network Simulator Page: 5-10

55 domains exist and inter-domain handovers become necessary. This works conceptually through the introduction of Mobile IPv6 on top of Proxy Mobile IPv6. The advantage of this concept is that the reverse tunnel - necessary within the Mobile IPv6 scenarios (SIM 01 and SIM 02) via the wireless link vanishes. Unfortunately, this advantage is only given if a mobile node (or network) moves within its home (or contracted) domain. Figure 5-4: Protocol stack visualization of SIM Key Issues of Implementation The key issue of this implementation is that the tunnelling between the Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) and the tunnelling between Local Mobility Anchor (LMA) and Home Agent if applicable (i.e. mobile node (or network) is currently located in a foreign domain) operates properly. Note that this point would increase the complexity of a real-world implementation. Additionally, the links between mobile node (or network) and Mobile Access Gateway (MAG) are realized through point-to-point links. This means that Router Advertisements, which are necessary to identify the lifelines of a link, cannot be transmitted as regularly recommended in the base specifications of Neighbor Discovery. This is based on the fact that PPP links induce unicast characteristic (even via a wireless medium), thereby increasing the link load drastically dependent on the amount of cell members present within a communication cell due to the inability of multicasting packets to all members. In general it is unclear how a real aeronautical implementation would solve link detection and authentication in home and foreign domains. Experience with commercial implementations (e.g. 3GPP) indicates that this can be realized via the L2 interface. For the simulation it has been assumed that link detection and authentication works within one round trip time in the home domain. The foreign domain needs to be detected first (which takes long). Furthermore it has to be noted that moving the mobility solution into the network increases the load of the network itself. Specification of the End-To-End ATM Network Simulator Page: 5-11

56 Configurable Parameters Additionally to the parameters configured in SIM 01 the following parameters apply. PMIP_INITIAL_BINDACK_TO=3.5 PROXY_BINDING_UPDATE_SIZE=194 PROXY_BINDING_ACK_SIZE=174 This parameter identifies the time interval unit a proxy binding update message is re-transmitted if no proxy binding acknowledgment was received. This parameter indicates the size (value given in byte) of a Proxy Binding Update sent from Mobile Access Gateway (MAG) towards the Local Mobility Anchor (LMA). This message is sent only via the ground-network, it includes: IPv6 header (40 byte) Destination Options Header (2 byte) Home Address Destination Option (18 byte) Mobility Header (6 byte) Binding Update (6 byte) Mobile Network Prefix Option (20 byte) - 2 times AOC/ATC or AAC/APC Mobile Network Identifier (38 byte) Timestamp Option (10 byte) Mobile Network Link Local Identifier (12 byte) Link Local Address (18 byte) Access Technology (4 byte) This parameter indicates the size (value given in byte) of a Proxy Binding Acknowledgment sent from a Local Mobility Anchor (LMA) towards a Mobile Access Gateway (MAG). This message is sent only via the ground-network, it includes: IPv6 (40 byte) Mobility Header (6 byte) Binding Acknowledgment (6 byte) Mobile Network Prefix Option (20 byte) - 2 times AOC/ATC or AAC/APC Mobile Network Identifier (38 byte) Timestamp Option (10 byte) Mobile Network Link Local Identifier (12 byte) Link Local Address (18 byte) Access Technology (4 byte) Table 5-3: Configurable parameters of SIM 04. In contrast to SIM 01 some of the parameter settings have been made differently. Specification of the End-To-End ATM Network Simulator Page: 5-12

57 MAX_RA_INTERVAL=8.0 MIN_RA_INTERVAL=6.0 LINK_MONITORING_INTERVAL=8.0 LINK_INCOMPLETE_INTERVAL=24.0 The maximum interval between consecutive Router Advertisements (value given in seconds). The MIPv6 specification recommends a value of 0.07 seconds, whereas the Neighbor Discovery protocol determines a value of 5 seconds. The minimum interval between consecutive Router Advertisements (value given in seconds). The MIPv6 specification allows a value as low as 0.03 seconds, where as the Neighborhood Discovery protocol determines a value of 3 seconds. The link monitoring interval is set to the same value of maximum router advertisement interval (value given in seconds). Thereby, new advertisements are definitely captured within one interval. The incomplete interval is set to three times the maximum router advertisement interval (value given in seconds). Table 5-4: Changed parameter settings in comparison to SIM Key Observations of Scenario Due to the fact that the wireless link has to be realized through a point-to-point link the amount of Router Advertisements sent for each individual aircraft (i.e. mobile network) cannot be high. (Note: Standard MIPv6 settings would result in 17 kbps of RA traffic per A/C.) This increases the connectivity gap when moving from one PMIPv6 domain towards another one according to the increase of the MAX_RA_INTERVAL parameter (note: LINK_INCOMPLETE_INTERVAL = 3 * MAX_RA_INTERVAL). If the mobile network stays within the home domain, the overhead via the wireless link is drastically reduced, but this is bought for a complexity increase within the ground network and a loss of moderately fast sub-network movement detection due to the higher MAX_RA_INTERVAL setting, as the RA frequency has to be reduced to not incur too much overhead on the wireless link due to PPP operation. Additionally note that the overhead reduction via the wireless link reduces the end-to-end latency Simulation Scenario High Level Overview Simulation scenario 05 (SIM 05) uses network based mobility with functions of the Media Independent Handover framework, the North-Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. In principle SIM 05 is similar to SIM 04 except that a movement between different PMIPv6 domains is detected faster thanks to the implemented MIH functions. Specification of the End-To-End ATM Network Simulator Page: 5-13

58 Figure 5-5: Protocol stack visualization of SIM Configurable Parameters The taken parameters for this scenario are identical to the one of simulation scenario 04. The only difference is that MIH functions are loaded onto the protocol stack of the mobile router and the Mobile Access Gateway (MAG) Key Observations of Scenario The same observations are valid for SIM 04 as for SIM 05, except that handovers between PMIPv6 domains are faster (up to 8 times) Simulation Scenario High Level Overview Simulation scenario 06 (SIM 06) makes use of the Global Home Agent to Home Agent (Global HAHA) protocol. SIM 06 uses node based mobility, the North-Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. The difference to SIM 01 is that before a new binding update from a newly attached network can be sent, the closest home agent has to be determined. This is done through the Dynamic Home Agent Address Discovery (DHAAD) protocol. Afterwards bindings are sent towards the topologically seen closest home agent. The Global HAHA protocol shall reduce unnecessary routing via a home agent if the respective home agent is far away from the correspondent node and/or the mobile node. In order to do so the home agents themselves have to synchronize each other within their domain Key Issues of Implementation Key issue of the implementation is that anycast has to work properly in order to find the closest home agent. Additionally, the synchronization among all home agents has to work properly Configurable Parameters Additionally to the parameters of SIM 01 the following parameters are valid for SIM 06 DHAAD_REQEUST_MSG_SIZE=48 This parameter indicates the size (value given in byte) of a Dynamic Home Agent Address Detection Request message, it includes: IPv6 Header (40 byte) ICMPv6 message DHAAD Request (8 byte) Specification of the End-To-End ATM Network Simulator Page: 5-14

59 DHAAD_REPLY_MSG_SIZE=60 This parameter indicates the size (value given in byte) of a Dynamic Home Agent Address Detection Reply message, it includes: IPv6 Header (40 byte) ICMPv6 message DHAAD Reply (20 byte) Table 5-5: Configurable parameters of SIM 06. The Binding Updates and Binding Acknowledgments support the protocol extensions necessary for the HAHA protocol Key Observations of Scenario SIM 06 does not show significant performance increase on the end-to-end latency due to the fact that most of the end-to-end delay is caused by the wireless link. Furthermore, the real advantage of the Global HAHA protocol would become significant if a specific aircraft is far away from its home network and would communicate with a correspondent node close by. This is most likely the case for inter-continental/long-haul flights that have not been simulated though. That is, the Global HAHA protocol may show significant improvements in this case. The additional round trip time of the DHAAD procedure can be seen in the handover statistics Key Observations in intercontinental Scenario In order to investigate the intercontinental case the same simulation has been performed filtering out all European aircraft. Only aircraft with primary home agents in the USA or Japan were considered. In this case the effects of RO become clearly visible. Gains are in the order of one inter-continental round-trip time Simulation Scenario High Level Overview Simulation scenario 07 (SIM 07) is the reference scenario in order to evaluate DiffServ Service behaviour; it uses node based mobility protocols (i.e. Mobile IPv6), the North- Atlantic air traffic model, and constant bit rate traffic generators for all communication endpoints. The various protocol stacks of the individual participants of the simulation (i.e. net nodes) look like as depicted in Figure 5-6. The client and server instances are producing data streams dedicated for each other. The network between client and server consists of a mobile router, a home agent, and several routers distributed along the path. As Figure 5-6 shows every net node instantiates IPv6, the communication endpoints (i.e. client and server) instantiate UDP and CBR traffic generators, and Mobile IPv6 (MIPv6) is instantiated by the mobile routers and home agents. Thereby, MIPv6 also includes NEMO capabilities. Note that the bottleneck is the wireless link and the queuing discipline at the mobile router and access router, respectively, has been chosen to be a first come first serve discipline. Furthermore, the link selection algorithm is based on a simple preference based table depicted in Table 5-1. For the DiffServ scenarios 8 different traffic streams in each direction have been produced. Specification of the End-To-End ATM Network Simulator Page: 5-15

60 Figure 5-6: Protocol stack visualization of SIM Key Issues of Implementation The key issues of the implementation are similar to those of SIM Configurable Parameters In comparison to SIM 01 the available data rate per user via the wireless link has been considerably reduced in order to create congestion at the wireless link. LINK3_PER_USER_CAPACITY_FL=3.5 LINK3_PER_USER_CAPACITY_RL=3.5 LINK4_PER_USER_CAPACITY_FL=3.5 LINK4_PER_USER_CAPACITY_RL=3.5 LINK5_PER_USER_CAPACITY_FL=3.5 LINK5_PER_USER_CAPACITY_RL=3.5 LINK6_PER_USER_CAPACITY_FL=3.5 LINK6_PER_USER_CAPACITY_RL=3.5 LINK8_PER_USER_CAPACITY_FL=3.5 This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 3 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 3 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 4 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 4 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 5 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 5 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 6 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 6 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 8 on the forward link (i.e. ground to aircraft). Specification of the End-To-End ATM Network Simulator Page: 5-16

61 LINK8_PER_USER_CAPACITY_RL=3.5 LINK9_PER_USER_CAPACITY_FL=3.5 LINK9_PER_USER_CAPACITY_RL=3.5 This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 8 on the reverse link (i.e. aircraft to ground). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 9 on the forward link (i.e. ground to aircraft). This parameter determines the amount of user capacity (value given in kilobits per second) via the wireless link-type 9 on the reverse link (i.e. aircraft to ground). Table 5-6: Changed parameter settings in comparison to SIM Key Observations of Scenario Key observations are similar to SIM 01, except that end-to-end delay is increased due to less data capacity of the wireless link Simulation Scenario High Level Overview The difference to SIM 07 is that within simulation scenario 08 (SIM 08) the router endpoints of the wireless link implement a DiffServ queuing discipline (priority scheduling). Everything else is similar to SIM Configurable Parameters Figure 5-7: Protocol stack visualization of SIM 08. Parameter setting is the same as of SIM Key Observations of Scenario DiffServ favours packets with higher priority, as this can be observed from the packet error rates and from the end-to-end delays Simulation Scenario 9 & 10 Removed. See Appendix A. Specification of the End-To-End ATM Network Simulator Page: 5-17

62 Simulation Scenario 11 & 12 Simulation scenario 11 (SIM 11) and simulation scenario 12 (SIM 12) demonstrate advantages of dynamic link selection (multiple attribute decision making). For the analysis of the link selection algorithm based on multiple attribute decision making, the used simulation scenario was modified from the originally planned ones. For the analysis of the link selection, the assessment of individual flights and the aggregated behaviour of several flights are meaningful. For this reason the analysis of the scenario has been limited to 20 aircraft in order to allow a detailed assessment of each of them. Thereby a link selection instance present at the mobile router and the home agent determines which link shall be selected to send a packet for reverse link and forward link transmissions, respectively. Thereby, the decision in the simulations is based on current SNR values, available bandwidth, expected mean delay, and user preferences. Figure 5-8: Protocol stack visualization of SIM 11 & SIM Key Issues of Implementation It is important to keep the data on the current link situation synchronous between mobile router and home agent (separate transmission protocol). For operation as intended it is necessary to provide up-to-date information on the link properties. For this reason the duration of the measurement interval is important to avoid using too old information. For the simulations performed here a value of 100 ms for the measurement intervals was found sufficient. While in general every information about the link load as measured by the terminal equipment is always representing the situation of a slightly past point in time, the fact that packet transmissions always take a while on bandwidth limited links as present here makes it still possible to use this information as indication of the actual situation. While the real situation may be slightly different, the channel load situation will likely not be entirely different, given that the link load is measured with an appropriate regularity. The frequency with which channel load information should be measured is hereby link dependent and cannot be quantified in a generic way. How these measurement reports are generated is dependent on the link properties and a task of the link equipment. The need to measure the actual link load very often is not critical if it is done in the on-board link equipment. Besides the proper setting of measurement intervals, it is of high importance to account for the fact that link measurements are done by each airborne router independent of other aircraft, i.e. unsynchronized. Specification of the End-To-End ATM Network Simulator Page: 5-18

63 For an entire synchronized measurement, all aircraft mobile routers would receive the same information what would result in the exact same decision, leading to oscillation effects Configurable Parameters Simulation scenario 11 and simulation scenario 12 have the same configuration parameters as SIM 01 except for the modified link selection algorithm of scenario 12. The link measurement interval was set to 100 ms. Table 5-7 displays the link preference table that was used in the simulations. Table 5-7: Used preference table for the simulations Link Type ATS AOC AAC APC Link Link Link Link Link Link Key Observations of Scenario For proper operation the link measurement interval is of high importance. The measurement interval is link dependent and for the simulations a value of 100 ms was used. The second important precondition for proper information is implementation of the uncorrelated measurements of the mobile routers since otherwise synchronized information leads to synchronized decisions. Key observation of this scenario is that the dynamic multiple attribute decision making link selection achieves the goal to balance the load among available links while also user preferences are considered in the decision process. While the intended functionality was shown for the local scenario with 20 aircraft, the investigation of the observed effects among the involved aircraft in a large scale simulation, involving many more aircraft deserves additional attention and is subject for future work. In particular an analysis of a possible change in the stability behaviour for such a high population scenario is of interest, as well as a performance, complexity and signalling overhead comparison with a central link assignment functionality placed on the ground Simulation Scenario High Level Overview Simulation Scenario 13 (SIM 13) is the reference scenario for TCP performance simulations. Based on SIM 01 the client and server communication endpoints load different simulation software onto their stack (i.e. adapted TCP stack). First the TCP Specification of the End-To-End ATM Network Simulator Page: 5-19

64 software has to be loaded. Additionally, a different data generation is loaded namely the COCRv2 data traffic model. The TCP simulations are using a separate connection per service class (i.e. QoS). This means that per instance (i.e. server & client) up to 8 different connections are open simultaneously. During the course of the simulation this connections are kept open until either the aircraft leaves the simulation coverage zone or the communication endpoint changes. CBR / COCRv2 CBR / COCRv2 TCP MIPv6 MIPv6 TCP IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 L2 interface L2 interface L2 interface L2 interface L2 interface L2 interface Client Mobile Router A/G Router Home Agent Router Server Key Issues of Implementation Figure 5-9: Protocol visualization of SIM 13. For simulation scenario 13, TCP Reno (RFC 793 and RFC 2001) has been implemented in detail Configurable Parameters Additional parameters in comparison to SIM 01, configurable for SIM 13 are given in the table below. MAX_SEGMENT_LIFETIME=10 MAX_TRANSFER_UNIT=1024 APPLICATION_BUFFER_SIZE= MAX_RX_WINDOW_FL=65536 MAX_RX_WINDOW_RL=65536 INITIAL_CONGESTION_WINDOW=1024 INITIAL_TIMEOUT=60 The maximum segment lifetime parameter determines the amount of time a segment could theoretically survive within the network (value given in seconds). The maximum transfer unit (MTU) determines the amount of data, which is allowed to be transferred within a single TCP segment (value given in bytes). The size of the application layer buffer (value given in bytes). If the application layer buffer is full, packets are dropped. The maximum value of the receive window for forward link transmissions (value given in bytes). I.e. no window scaling is applied. The maximum value of the receive window for reverse link transmissions (value given in bytes). I.e. no window scaling is applied. The initial value of the parameter cwnd. Usually set to the size of a single MTU (value given in bytes). The initial timeout value interval for re-transmission of TCP segments without acknowledgment (value given in seconds). Specification of the End-To-End ATM Network Simulator Page: 5-20

65 Table 5-8: Configurable parameters for SIM Key Observations of Scenario TCP works reliable yet not optimal in this reference scenario Simulation Scenario High Level Overview The difference of SIM 13 to simulation scenario 14 (SIM 14) is that window scaling is applied to the TCP software and the initial congestion window is increased. The initial congestion window is usually one segment (i.e. one MTU) Configurable Parameters INITIAL_CONGESTION_WINDOW=11264 MAX_RX_WINDOW_FL= MAX_RX_WINDOW_RL= The initial value of the parameter cwnd. Usually set to the size of a single MTU. Here, this corresponds to 11 TCP segments. The maximum value of the receive window for forward link transmissions (value given in bytes). I.e. window scaling is applied. The maximum value of the receive window for reverse link transmissions (value given in bytes). I.e. window scaling is applied. Table 5-9: Changed parameter settings in comparison to SIM Key Observations of Scenario Window scaling and setting the initial window to a larger size than a single MTU, did not show significant improvements over the reference scenario. Increasing the initial window to several MTU segments is "unproductive" within this environment, because the per user bandwidth capacity was limited to 20 kbits/sec. Increasing the initial window means that a TCP may start to transmit more than one MTU right from the beginning of a data communication exchange, hence increasing throughput and decreasing delay. But this is only possible if the data link layer underneath is supporting data rates up to and beyond that window size. Within this simulation scenario a window of 4 segments accounts for ~32 kilobits, this means that segments have to be buffered for some time, probably causing spurious timeouts. The initial window setting has only an effect on large data exchanges with several MTU segments, here spurious timeouts may occur until the real congestion window (cwnd) is found. Applications with small data exchanges are not affected by such a setting. Increasing the receive buffers of the simulated entities (up to 256 Kbytes) - e.g. client and server - yields not the wished effect of larger throughput. The reason therefore is simple. Within our simulation environment we have a limited "per user" data capacity, which is 20 kbits/sec. TCP itself can only increase it's transmission rate if acknowledgments are coming back quick (this is of course relative and related to window size and bandwidth availability) and before a re-transmission timer goes off. This means that TCP is adjusting it's transmission rate to the available bandwidth capacity (and also congestion on the network), which is in our case rather low in comparison to the receive Specification of the End-To-End ATM Network Simulator Page: 5-21

66 window. This means that the receive window cannot be exploited, hence it does not have any effect on the data exchange itself. Window scaling does only show significant benefits for "long fat networks. That is, on networks where the bandwidth delay product is high Simulation Scenario 15 The load balancing scenario has not been simulated separately since the effects of load balancing by means of the dynamic link selection algorithm (multiple attribute decision making) is already covered by simulation scenario 12 (local scenario involving 20 aircraft). The key observations are thus the same as for scenario Simulation Scenario High Level Overview Simulation scenario 16 has basically the same configuration as SIM 13, except that all terrestrial links fail after a certain period of time within the simulation scenario. That is, the mobile nodes have to detect the loss of connectivity and switch over to alternative available communication links (i.e. satellite links). This scenario used the simple link selection algorithm Configurable Parameters Figure 5-10: Stack visualization of SIM 16. This simulation scenario has the same configuration as of SIM Key Observations of Scenario The results confirm that the NEWSKY protocols can indeed recover from terrestrial link failure events. The TCP transport layer protocol recovers from the link loss after some time of increased latency and the switch to the satellite system. No packets were lost as TCP cared for the retransmission Specification of the End-To-End ATM Network Simulator Page: 5-22

67 Simulation Scenario High Level Overview Simulation scenario 17 has basically the same configuration as SIM 13, except that it implements DiffServ and uses the COCRv2 data traffic pattern for the North-Atlantic flight traffic pattern Key Issues of Implementation Similar to SIM 01 and SIM Configurable Parameters Similar to SIM 01 and SIM Key Observations of Scenario Figure 5-11: Stack visualization of SIM 17. The observations of this scenario were equivalent to the observations of the previous scenarios (implementing the relevant algorithms independently) and thus provided a cross checking of the results. Specification of the End-To-End ATM Network Simulator Page: 5-23

68 6 Results This section provides an overview of some key observations of the simulation results. The detailed assessment of the simulation results is provided in report D20 [30]. The assessment of the NEWKSY results has shown clearly that the ATN/IPS mobile IPv6 protocols work reliably. However, it has also become apparent that both MIPv6/NEMO and PMIPv6 produce significant overhead on the wireless link. The benefits of the combination of PMIPv6 with MIPv6/NEMO over stand-alone MIPv6/NEMO are uncertain in the aeronautical domain: Stand-alone MIPv6/NEMO allows the use of multicast router advertisements. Although assigning a common prefix to all mobiles is a non-standard deployment according to RFC3314, this approach allows for a significant reduction of signalling traffic on the wireless link. PMIPv6 on the other side requires sending addressed router advertisements to each mobile router. This has the consequence that the load of the wireless link may be significantly increased in highly populated radio cells. The exact amount of signalling traffic depends on the RA interval and the number of user per cell, but may be prohibitive in the case of low-bandwidth aeronautical links. A benefit of PMIPv6 is that the MIPv6/NEMO tunnel is not required in the home domain. This results in small performance gains and a reduction of the wireless link load. However, this benefit is only given in the home domain and may be diminished by header compression. MIPv6/NEMO route optimization brings no significant performance benefits in intra- European scenarios as the end-to-end latency is dominated by the wireless links. In the case of inter-continental flights the effects of the Global HAHA RO are however significant. As the global HAHA protocol brings no significant performance gains in the intracontinental case, increasing number of home agents per continent (4 in the simulations) will not result in significant performance gains either. That is, the number of home agents per continent may be determined only by redundancy and operational requirements. At least one home agent per continent is however required to benefit from Global HAHA route optimization. Our assessment has shown clearly that a fast and efficient MIPv6/NEMO or PMIPv6 deployment will require a sophisticated layer 2 interface to determine the link status and to perform link layer authentication. Link layer authentication is required not only for security reasons, but also for PMIPv6, which requires link layer identification of mobiles. IEEE is a promising solution that should be considered in the development of the future aeronautical radio system. Specification of the End-To-End ATM Network Simulator Page: 6-1

69 Table 6-1: Simulation input files. Scenario Reference Scenario Description Report File SIM_01 Node based mobility SIM_01_N_Flight18766_P256.xml.gz.iris.input.html SIM_01_N_Flight18766_P512.xml.gz.iris.input.html SIM_01_N_Flight62647_P256.xml.gz.iris.input.html SIM_01_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_01_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.iris.input.html Simulation_Scenario_01_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.iris.input.html im_02 SIM_04 SIM_05 Node based mobility with make before break handover Combination of node based mobility and network based mobility Combination of node based mobility and network based mobility with make before break handover SIM_02_N_Flight18766_P256.xml.gz.iris.input.html SIM_02_N_Flight18766_P512.xml.gz.iris.input.html SIM_02_N_Flight62647_P256.xml.gz.iris.input.html SIM_02_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_02_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.iris.input.html Simulation_Scenario_02_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.iris.input.html SIM_04_N_Flight18766_P256.xml.gz.iris.input.html SIM_04_N_Flight18766_P512.xml.gz.iris.input.html SIM_04_N_Flight62647_P256.xml.gz.iris.input.html SIM_04_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_04_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.iris.input.html Simulation_Scenario_04_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.iris.input.html SIM_05_N_Flight18766_P256.xml.gz.iris.input.html SIM_05_N_Flight18766_P512.xml.gz.iris.input.html SIM_05_N_Flight62647_P256.xml.gz.iris.input.html SIM_05_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_05_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.iris.input.html Specification of the End-To-End ATM Network Simulator Page: 6-2

70 Simulation_Scenario_05_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.iris.input.html SIM_06 Node based mobility with route optimization SIM_06_N_Flight18766_P256.xml.gz.iris.input.html SIM_06_N_Flight18766_P512.xml.gz.iris.input.html SIM_06_N_Flight62647_P256.xml.gz.iris.input.html SIM_06_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_06_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.iris.input.html Simulation_Scenario_06_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.iris.input.html SIM_07 SIM_08 Traffic management reference, dual routers (link capacity 3.5 kbps) Traffic management, dual routers (link capacity 3.5 kbps) SIM_07_C_Flight25866_P256.xml.gz.iris.input.html SIM_07_C_Flight25866_P512.xml.gz.iris.input.html SIM_07_C_Flight67168_P256.xml.gz.iris.input.html SIM_07_C_Flight67168_P512.xml.gz.iris.input.html Simulation_Scenario_07_NorthAtlantic_Final_NP_Rate025_P256_SEC1000.xml.gz.iris.input.html Simulation_Scenario_07_NorthAtlantic_Final_NP_Rate025_P512_SEC1000.xml.gz.iris.input.html SIM_08_C_Flight25866_P256.xml.gz.iris.input.html SIM_08_C_Flight25866_P512.xml.gz.iris.input.html SIM_08_C_Flight67168_P256.xml.gz.iris.input.html SIM_08_C_Flight67168_P512.xml.gz.iris.input.html Simulation_Scenario_08_NorthAtlantic_Final_NP_Rate025_P256_SEC1000.xml.gz.iris.input.html Simulation_Scenario_08_NorthAtlantic_Final_NP_Rate025_P512_SEC1000.xml.gz.iris.input.html SIM_11 Link assignment Reference SIM_11_and_SIM_12.xls SIM_12 SIM_15 Link assignment Load balancing (scenarios merged) SIM_11_and_SIM_12.xls SIM_13 Transport layer adaptation reference SIM_13_N_Flight18766_P256.xml.gz.iris.input.html SIM_13_N_Flight18766_P512.xml.gz.iris.input.html SIM_13_N_Flight62647_P256.xml.gz.iris.input.html SIM_13_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_13_output_P256.xml.gz.iris.input.html Specification of the End-To-End ATM Network Simulator Page: 6-3

71 Simulation_Scenario_13_output_P512.xml.gz.iris.input.html SIM_14 Transport layer adaptation SIM_14_N_Flight18766_P256.xml.gz.iris.input.html SIM_14_N_Flight18766_P512.xml.gz.iris.input.html SIM_14_N_Flight62647_P256.xml.gz.iris.input.html SIM_14_N_Flight62647_P512.xml.gz.iris.input.html Simulation_Scenario_14_output_P256.xml.gz.iris.input.html Simulation_Scenario_14_output_P512.xml.gz.iris.input.html SIM_16 Redundancy SIM_16_Flight19093_P256_500SEC.xml.gz.iris.input.html SIM_16_Flight19093_P256_1000SEC.xml.gz.iris.input.html SIM_16_Flight19093_P512_500SEC.xml.gz.iris.input.html SIM_16_Flight19093_P512_1000SEC.xml.gz.iris.input.html Simulation_Scenario_16_output_P256.xml.gz.iris.input.html Simulation_Scenario_16_output_P256_500SEC.xml.gz.iris.input.html Simulation_Scenario_16_output_P256_1000SEC.xml.gz.iris.input.html Simulation_Scenario_16_output_P512.xml.gz.iris.input.html Simulation_Scenario_16_output_P512_500SEC.xml.gz.iris.input.html Simulation_Scenario_16_output_P512_1000SEC.xml.gz.iris.input.html SIM_17 Global performance assessment Table 6-2: Simulation reports. Scenario Reference Scenario Description Report File SIM_01 Node based mobility SIM_01_N_Flight18393_P256.xml.gz.newsky.result.html SIM_01_N_Flight18393_P512.xml.gz.newsky.result.html SIM_01_N_Flight18766_P256.xml.gz.newsky.result.html SIM_01_N_Flight18766_P512.xml.gz.newsky.result.html Specification of the End-To-End ATM Network Simulator Page: 6-4

72 SIM_01_N_Flight62647_P256.xml.gz.newsky.result.html SIM_01_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_01_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.newsky.result.html Simulation_Scenario_01_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.newsky.result.html Simulation_Scenario_01_Continental_USA_CAN_JAP.xml.gz.newsky.result.html SIM_02 SIM_04 SIM_05 Node based mobility with make before break handover Combination of node based mobility and network based mobility Combination of node based mobility and network based mobility with make before break handover SIM_02_N_Flight18393_P256.xml.gz.newsky.result.html SIM_02_N_Flight18393_P512.xml.gz.newsky.result.html SIM_02_N_Flight18766_P256.xml.gz.newsky.result.html SIM_02_N_Flight18766_P512.xml.gz.newsky.result.html SIM_02_N_Flight62647_P256.xml.gz.newsky.result.html SIM_02_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_02_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.newsky.result.html Simulation_Scenario_02_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.newsky.result.html SIM_04_N_Flight18393_P256.xml.gz.newsky.result.html SIM_04_N_Flight18393_P512.xml.gz.newsky.result.html SIM_04_N_Flight18766_P256.xml.gz.newsky.result.html SIM_04_N_Flight18766_P512.xml.gz.newsky.result.html SIM_04_N_Flight62647_P256.xml.gz.newsky.result.html SIM_04_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_04_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.newsky.result.html Simulation_Scenario_04_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.newsky.result.html SIM_05_N_Flight18393_P256.xml.gz.newsky.result.html SIM_05_N_Flight18393_P512.xml.gz.newsky.result.html SIM_05_N_Flight18766_P256.xml.gz.newsky.result.html SIM_05_N_Flight18766_P512.xml.gz.newsky.result.html SIM_05_N_Flight62647_P256.xml.gz.newsky.result.html SIM_05_N_Flight62647_P512.xml.gz.newsky.result.html Specification of the End-To-End ATM Network Simulator Page: 6-5

73 Simulation_Scenario_05_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.newsky.result.html Simulation_Scenario_05_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.newsky.result.html SIM_06 SIM_07 SIM_08 Node based mobility with route optimization Traffic management reference, dual routers (link capacity 3.5 kbps) Traffic management, dual routers (link capacity 3.5 kbps) SIM_06_N_Flight18393_P256.xml.gz.newsky.result.html SIM_06_N_Flight18393_P512.xml.gz.newsky.result.html SIM_06_N_Flight18766_P256.xml.gz.newsky.result.html SIM_06_N_Flight18766_P512.xml.gz.newsky.result.html SIM_06_N_Flight62647_P256.xml.gz.newsky.result.html SIM_06_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_06_NorthAtlantic_Final_NP_Rate05_Packet256.xml.gz.newsky.result.html Simulation_Scenario_06_NorthAtlantic_Final_NP_Rate05_Packet512.xml.gz.newsky.result.html Simulation_Scenario_06_Continental_USA_CAN_JAP_NEW.xml.gz.newsky.result.html SIM_07_C_Flight25866_P256.xml.gz.newsky.result.html SIM_07_C_Flight25866_P512.xml.gz.newsky.result.html SIM_07_C_Flight67168_P256.xml.gz.newsky.result.html SIM_07_C_Flight67168_P512.xml.gz.newsky.result.html Simulation_Scenario_07_NorthAtlantic_Final_NP_Rate025_P256_SEC1000.xml.gz.newsky.result.html Simulation_Scenario_07_NorthAtlantic_Final_NP_Rate025_P512_SEC1000.xml.gz.newsky.result.html SIM_08_C_Flight25866_P256.xml.gz.newsky.result.html SIM_08_C_Flight25866_P512.xml.gz.newsky.result.html SIM_08_C_Flight67168_P256.xml.gz.newsky.result.html SIM_08_C_Flight67168_P512.xml.gz.newsky.result.html Simulation_Scenario_08_NorthAtlantic_Final_NP_Rate025_P256_SEC1000.xml.gz.newsky.result.html Simulation_Scenario_08_NorthAtlantic_Final_NP_Rate025_P512_SEC1000.xml.gz.newsky.result.html SIM_11 Link assignment Reference SIM_11_and_SIM_12.xls SIM_12 SIM_15 Link assignment Load balancing (scenarios merged) SIM_11_and_SIM_12.xls SIM_13 Transport layer adaptation reference SIM_13_N_Flight18393_P256.xml.gz.newsky.result.html Specification of the End-To-End ATM Network Simulator Page: 6-6

74 SIM_13_N_Flight18393_P512.xml.gz.newsky.result.html SIM_13_N_Flight18766_P256.xml.gz.newsky.result.html SIM_13_N_Flight18766_P512.xml.gz.newsky.result.html SIM_13_N_Flight62647_P256.xml.gz.newsky.result.html SIM_13_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_13_output_P256.xml.gz.newsky.result.html Simulation_Scenario_13_output_P512.xml.gz.newsky.result.html SIM_14 Transport layer adaptation SIM_14_N_Flight18393_P256.xml.gz.newsky.result.html SIM_14_N_Flight18393_P512.xml.gz.newsky.result.html SIM_14_N_Flight18766_P256.xml.gz.newsky.result.html SIM_14_N_Flight18766_P512.xml.gz.newsky.result.html SIM_14_N_Flight62647_P256.xml.gz.newsky.result.html SIM_14_N_Flight62647_P512.xml.gz.newsky.result.html Simulation_Scenario_14_output_P256.xml.gz.newsky.result.html Simulation_Scenario_14_output_P512.xml.gz.newsky.result.html SIM_16 Redundancy SIM_16_Flight19093_P256_500SEC.xml.gz.newsky.result.html SIM_16_Flight19093_P256_1000SEC.xml.gz.newsky.result.html SIM_16_Flight19093_P512_500SEC.xml.gz.newsky.result.html SIM_16_Flight19093_P512_1000SEC.xml.gz.newsky.result.html SIM_16_Flight65156_P256_500SEC.xml.gz.newsky.result.html SIM_16_Flight65156_P256_1000SEC.xml.gz.newsky.result.html SIM_16_Flight65156_P512_500SEC.xml.gz.newsky.result.html SIM_16_Flight65156_P512_1000SEC.xml.gz.newsky.result.html Simulation_Scenario_16_output_P256_500SEC.xml.gz.newsky.result.html Simulation_Scenario_16_output_P256_1000SEC.xml.gz.newsky.result.html Simulation_Scenario_16_output_P512_500SEC.xml.gz.newsky.result.html Simulation_Scenario_16_output_P512_1000SEC.xml.gz.newsky.result.html Specification of the End-To-End ATM Network Simulator Page: 6-7

75 Simulation_Scenario_16.xml.gz.newsky.result.html Simulation_Scenario_16_all_Links.xml.gz.newsky.result.html Simulation_Scenario_16_no_terrestrial_links.xml.gz.newsky.result.html SIM_17 Global performance assessment Specification of the End-To-End ATM Network Simulator Page: 6-8

76 7 Acronyms and Abbreviations 3GPP 3rd Generation Partnership Project 3GPP2 3rd Generation Partnership Project 2 4G Fourth-Generation Communications System A/A Air-to-Air A/C A/G AAA Aircraft Air to Ground Authentication, Authorization, and Accounting AAC Airline Administrative Communication ACARS Aircraft Communications Addressing and Reporting System ACK Acknowledgement ACP ACSP ADN AEEC AFDX AH AN ANFS ANSP AOA AOC AP APC APT AR ATA ATM ATN ATN/IPS ATS BA BGP bps Aeronautical Communications Panel (ICAO) Air Communication Service Provider Aircraft Data Network Airlines Electronic Engineering Committee Avionics Full-Duplex Switched Ethernet Authentication Header Access Network Aircraft Network and File Server Air Navigation Service Provider Autonomous Operations Area Airline Operational Communication Access Point Aeronautical Passenger Communication Airport Access Router Air Transport Association Air Traffic Management Aeronautical Telecommunications Network IP based ATN Air Traffic Services Binding Acknowledgment Border Gateway Protocol bits per second Specification of the End-To-End ATM Network Simulator Page: 7-1

77 BS BU CA CDM CFMU CIA CLNP CLTP CMU CN CoA COPP CoS COSP COTS DAD DBSy DCOM DHCP DiffServ DNS DoS DP DSP DTLS DVB- RCS/S2 ECC EJB EMS ENR Base Station Binding Update Certification Authority Collaborative Decision Making Central Flow Management Unit Continuity, Integrity and Availability Connectionless Network Protocol Connectionless Transport Protocol Communication Management Unit Correspondent Node Care-of Address Connection Oriented Presentation Protocol Class of Service Connection Oriented Session Protocol Commercial Off The Shelf Duplicate Address Detection Domain Based Security Distributed Component Object Model Dynamic Host Configuration Protocol Differentiated Services Domain Name System Denial of Service Decision Point Datalink Service Provider Datagram Transport Layer Security Digital Video Broadcasting - Return Channel Satellite/2nd Generation Elliptic curve cryptography Enterprise Java Beans Enterprise Messaging System En Route (domain) E-OCVM European Operational Concept Validation Methodology FAA FBU FDDI Federal Aviation Administration Fast Binding Update Fiber Distributed Data Interface Specification of the End-To-End ATM Network Simulator Page: 7-2

78 FIPS Federal Information Processing Standards FMIPv6 Fast Handovers for MIPv6 FQDN Fully-Qualified Domain Name FRS Future Radio System FTP File Transfer Protocol GEO Geostationary GERAN GSM/EDGE Radio Access Network GNSS Global Navigation Satellite System GPS Global Positioning System GSM Global System for Mobile Communications HA Home Agent HAHA Home Agent to Home Agent HESSID Homogenous Extended Service Set Identifier HMAC Keyed-hash message authentication code HO Handover HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure ICAO International Civil Aviation Organization ICMPv6 Internet Control Message Protocol version 6 IDRP Inter-Domain Routing Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange IKEv2 Internet Key Exchange Protocol IM Information Management IMAP Internet Message Access Protocol IntServ Integrated Services IP Internet Protocol IPS Internet Protocol Suite IPSec Internet Protocol Security IPv4 Internet Protocol Version 4 IPv6 Internet Protocol version 6 ITU International Telecommunication Union JCG Joint Coordination Group L2 Layer 2 Specification of the End-To-End ATM Network Simulator Page: 7-3

79 L3 Layer 3 LAN Local Area Network LDACS L-band Digital Aeronautical Communication System LFN Local Fixed Node MAC Medium Access Control MAG Mobile Access Gateway MAGIC Manager of Air-Ground Interface Communications MASPS Minimum Aviation System Performance Standards MCC- Mobile Country Code - Mobile Network Code MNC MCoA MICS MIES MIH MIHF MIHO MIIS Multiple Care-of Addresses Media Independent Command Service Media Independent Event Service Media Independent Handover MIH Function Mobile-initiated HO MIPv6 Mobile IP version 6 MIRON MLD MN MNP MOBIKE MoD MONAMI6 MSP MT MTU MU NAI NAS NBMA ncoa Media Independent Information Service Mobile IPv6 Route Optimization for NEMO Multicast Listener Discovery Mobile Node Mobile Network Prefix IKEv2 Mobility and Multihoming Protocol Ministry of Defence Mobile Nodes and Multiple Interfaces in IPv6 Mobility Service Provider Mobile Terminal Maximum Transfer Unit Management Unit Network Access Identifier National Airspace System (US) Non-Broadcast Multiple Access next CoA Specification of the End-To-End ATM Network Simulator Page: 7-4

80 ND Neighbor Discovery NEC Network Enabled Capability NEMO NEtwork MObility NIHO Network-initiated HO NIS Network Infrastructures and Security NIST National Institute of Standards and Technology NOC Network Operations Center NSAP Network Service Access Point ORP Oceanic, Remote, Polar OSI Open Systems Interconnection Reference Model pcoa previous CoA PDU Protocol Data Unit PEP Performance Enhancing Proxy PIAC Peak Instantaneous Aircraft Count PKI Public Key Infrastructure PLMN Public Land Mobile Network PMC Program Management Committee (RTCA) PMIP Proxy MobileIP PMIPv6 Proxy Mobile IPv6 PoA Point of Attachment POP Post Office Protocol PoS Point of Service QoS Quality of Service RAL Radio Access Layer RCTP Required Communications Technical Performance RDF Resource Description Framework RFC Request for Comments RO Route Optimization RP Reference Point RPC Remote Procedure Call RSVP Resource ReSerVation Protocol RTO Retransmission Timeout RTT Round Trip Time SAI Systems Architecture and Interfaces Specification of the End-To-End ATM Network Simulator Page: 7-5

81 SAP SCTP SEND SES SINR SMTP SNIR SOA SOAP SONET SPARQL SSL SSO SWIM TCP TCP/IP TLS TLV TMA Service Access Point Stream Control Transport Protocol Secure Neighbor Discovery Single European Sky Signal to Interference and Noise Ratio Simple Mail Transfer Protocol Signal To Noise and Interference Ratio Service Oriented Architecture Service Oriented Architecture Protocol Synchronous optical networking SPARQL Protocol and RDF Query Language Secure Sockets Layer Security Service Object System Wide Information Management Transmission Control Protocol Transfer Control Protocol / Internet Protocol Transport Layer Security Type-Length-Value Terminal Manoeuvring Area TP4 Transport Protocol Class 4 UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol UMTS URI UTRAN VHF VPN WAN WCF Universal Mobile Telecommunications System Universal Resource Identifier UMTS Terrestrial Radio Access Network Very High Frequency Virtual Private Network Wide Area Network Windows Communication Foundation WiMAX Worldwide Interoperability for Microwave Access, i.e. IEEE WLAN WSDL WS-I Wireless LAN Web Services Description Language Web Services Interoperability X.25 Protocol suite for wide area networks; packet Specification of the End-To-End ATM Network Simulator Page: 7-6

82 switched X.500 Standard for directory services X.509 Standard for public-key infrastructure XKMS XML Key Management Specification XML Extensible Markup Language Specification of the End-To-End ATM Network Simulator Page: 7-7

83 8 References [1] NEWSKY project, Towards Evaluation Scenarios, discussion paper DP4.1, [2] NEWKY project, Technology Screening and Characterisation for Integration in NEWSKY Network, report D09, [3] [4] EUROCONTROL/FAA, Communications Operating Concept and Requirements for the Future Radio System (COCR), vers. 2, [5] EUROCONTROL/FAA, Future Communications Infrastructure Technology Investigations, Evaluation Scenarios, [6] NEWSKY project, Technical Approach to the ATM Network Topology Simulator, discussion paper DP4.2, [7] D. Comer, D. Stevens, 1998, Internetworking with TCP/IP Volume II, Volume II, Prentice Hall. [8] Roadmap for the Implementation of Data Link Services in European Air Traffic Management (ATM): Non-ATS Applications, Helios Technology, Sofreavia, IATA, Integra Consult, Airbus, February 2003 [9] D. Johnson, C. Perkins, and J. Arkko, Mobility Support in IPv6, RFC 3775, June [10] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, Network Mobility (NEMO) Basic Support Protocol, RFC 3963, Jan [11] P. Thubert, R. Wakikawa, and V. Devarapalli, "Global HA to HA protocol", draftthubert-mext-global-haha-00 (work in progress), March [12] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August [13] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, Neighbor Discovery for IP version 6 (IPv6), RFC 4861, Sept [14] S. Thomson, T. Narten and T. Jinmei, IPv6 Stateless Address Autoconfiguration, RFC 4862, September [15] Bauer, Christian; Ayaz, Serkan; Ehammer, Max; Gräupl, Thomas; Arnal, Fabrice (2008): Infrastructure-based Route Optimization for NEMO based on Combined Local and Global Mobility. In: MobiWorld 2008, ACM, Mobility Conference 2008, Yilan, Taiwan, September [16] NEWSKY Deliverable D14 Seamless Handover Strategies, [17] NEWSKY project, Simulation Scenarios for Concept Validation Deliverable D16, August [18] Peter Unger, Multiservice Traffic Analysis for Global Aeronautical Communications over Broadband Satellite Systems, Master s Thesis, Technische Universität Ilmenau, Sept [19] ETSI: Universal Mobile Telecommunications System (UMTS): Selection Procedures for the Choice of Radio Transmission Technologies of the UMTS. Technical Report TR v3.2.0, Aug Specification of the End-To-End ATM Network Simulator Page: 8-1

84 [20] O. Hersent, D. Gurle, J.P. Petit, IP Telephony: Packet Based Multimedia Communications System, Addison-Wesley, [21] Vern Paxson, Empirically Derived Analytic Models of Wide-Area TCP Connections, IEEE/ACM Trans. Networking, Vol. 2, Issue 4, August [22] Joachim Charzinski, Observations in Performance, Proc. ITC Specialist Seminar, Würzburg, Germany, July [23] D.Staehle, K. Leibnitz, P. Tran-Gia, Source Traffic Modelling of Wireless Applications, Technical Report No. 261, Institut für Informatik, Universität Würzburg, June [24] Balaji Kumar, Impact of Internet Traffic on Public Telephone Networks, New Telecom Quarterly, 1Q97. [25] ITU-T Recommendation G.114, One Way Transmission Time, May 2003 [26] C.-H. Rokitansky, M. Ehammer, and T. Gräupl, Communication Capacity Assessment for the Iris Satellite System, in Proc. 27th DASC, [27] NEWSKY Deliverable D11 NEWSKY Design Document, Version 1: , Version 2: [28] NEWSKY Deliverable D12 Efficient Resource Management Techniques, [29] NEWSKY Deliverable D18 Specification of the ATM Network Topology Simulator, [30] NEWSKY Deliverable D20 NEWSKY Performance Evaluation Results Assessment and Recommendations, 2009 [31] NEWSKY Deliverable D10 NEWSKY System Requirements Document, 2008 [32] NEWSKY Deliverable D15 NEWSKY Security Concept, [33] NEWSKY Deliverable D13 Advanced Routing Algorithms, Specification of the End-To-End ATM Network Simulator Page: 8-2

85 9 Appendix A - Deviations from D16 and D18 This section lists errata and changes of the simulation scenario definition in [17] and [29]. Changes to the network topology: There is now one AOC centres per E*, L* and non-european ICAO zones. The home countries of aircraft are determined by their by airline. The link quality is now computed according to a free space path loss model. The ICAO region aggregates of home agent coverage have been augmented with missing country codes as given in Table 9-1. Table 9-1: Home agent coverage. HA1 HA2 HA3 HA4 EI EF, EG, EK, EN, ES, EB, EL, EH, ED, LS LE, LI, LP, LF, LA, LW, LG, LT, LC, LL, LM, LN, LV EP, EV, EY, LB, LD, LH, LK, LR, LY, LZ, LO, LJ, LQ, EE, LU Changes to the scenario definitions: The redundancy scenario SIM_16 is now 400x400 nautical miles: First half with terrestrial links, second half without terrestrial links. Pure network based mobility SIM_03 removed as it cannot be implemented in reality. This approach would require that the whole ATN is a single PMIPv6 domain, i.e. that the ATN is a single administrative domain operated by a single service provider. Single router scenarios SIM_09, SIM_10 removed due to security concept. The pragmatic security concept of [32] requires separate routers for the operational and non-operational security domain. Single flights are filtered out for link selection and TCP scenarios SIM_11 SIM_14. SIM_07 and SIM_08 use now CBR traffic (8 CoS) over UDP. SIM_11 and SIM_12 use now CBR traffic (8 CoS) over UDP. SIM_12 merged with SIM-15: The load balancing scenario has not been simulated separately since the effects of load balancing by means of the dynamic link selection algorithm (multiple attribute decision making) is already covered by simulation scenario 12 (local scenario involving 20 aircraft). Specification of the End-To-End ATM Network Simulator Page: 9-1

86 10 Appendix B Detailed Protocol Descriptions The following protocol descriptions are mostly based on the respective RFCs that have been simplified for the ease of the implementation. These simplified versions are included in the subsequent sections. The protocols are based on the following assumptions: A Layer 2 Identifier (e.g. MAC address) is available that unambiguously identifies a mobile node s attachment to a base station/gateway. Every node has a globally unique L2 Identifier for every interface. Mobile Node specific information (e.g. L2 identifier, Home Agent address, home network prefix) is preconfigured IEEE Primitives This section specifies the primitives of the IEEE handover framework that will be implemented within the simulation environment. These primitives conform to those that have been selected in Deliverable 14 [16] and are as follows: Basic MIHF interfaces to the lower and higher layers: MIH_LINK_SAP and MIH_SAP MIH_Link_Going_Down MIH_Link_Down MIH_Link_Up MIH_Link_Detected MIH_Link_Actions In combination with the mobility protocol from [33], the functionality listed will allow make-before break strategies. Details about those primitives are specified below MIH_LINK_SAP & MIH_SAP The MIHF entities placement in the protocol stack is shown in Figure The MIHF is a functional entity that works between the link and the network layer. Note: In the implementation, the MIHF does not have to be placed at a specific place of the protocol stack, as user data is not flowing through it. Instead, it can be placed anywhere for as long as other modules (e.g. link, IP) can access functions of the MIHF. Specification of the End-To-End ATM Network Simulator Page: 10-1

87 The services relevant for the implementation are only the Command and the Event service. The interfaces that allow sending commands or retrieval of events from the MIHF are defined within this section. The word link in the following always refers to the on-board link/interface at the aircraft; similarly events and commands are only generated and consumed at the aircraft. Figure 10-1 Partial view of protocol stack with MIHF and interfaces MIH_LINK_SAP Link layer modules are communicating with the MIHF via the MIH_LINK_SAP. During start-up phase, links register with their interface ID at the MIHF to indicate their presence. Primitives of this category are listed as Link_Event. The parameters for registration are: Link ID, link characteristics (e.g. technology) MIH_ SAP MIH Users (e.g. decision point) are communicating with the MIHF via the MIH_SAP. During start-up phase, these users register with the MIHF to indicate their presence. Registration includes the following parameters: User ID IDs of the events the user would like to be notified of Specification of the End-To-End ATM Network Simulator Page: 10-2

88 Primitives of this category are listed as MIH_Link_Event. After a MIH User has subscribed to a specific event ID (MIH_Link_Event), it will be automatically notified as soon as the MIHF receives the corresponding Link_Event from a link. Note: User ID can also be provided by the MIHF in the registration acknowledgement. Note: Event IDs are specified in Section The parameters for registration are: User ID, Event ID(s) Handover Related Primitives The following are the handover specific primitives that are exchanged via the MIH_ SAP interface. Every primitive has a counterpart within the MIH_Link_SAP; these primitives omit the MIH_ prefix. The ID of MIH_Link_Event should be equal to that of the corresponding Link_Event. Similarly, the ID of Link_Command should be equal to that of the corresponding MIH_Link_Command MIH_Link_Going_Down This primitive is a predictive event indicating that the signal strength of the link has significantly decreased and that the link is therefore most likely going to be lost. The event is generated at the link, sent to the MIHF that in turn propagates it to all MIH Users that have registered for this event. This is also shown in Figure Note: Signal strength should be normalized to a value in the interval [0, 100]. This event should then be triggered ONCE if the signal strength falls to a value of 2 ( two ) or below. The parameters are: Link ID Figure 10-2 MIHF Event propagation MIH_Link_Down This primitive indicates that the link has lost the association to its base station, that no other base station is available and that the link can therefore not be used anymore for transmitting higher layer protocol data units. Specification of the End-To-End ATM Network Simulator Page: 10-3

89 The event is generated at the link, sent to the MIHF that in turn propagates it to all MIH Users that have registered for this event. This is also shown in Figure The parameters are: Link ID MIH_Link_Up This primitive indicates that the link has successfully finished the attachment procedure and that higher layer protocol data units can now be transmitted over this link. Note: This primitive should be triggered when the link has received the final connection establishment / handover acknowledgement from the base station. The event is generated at the link, sent to the MIHF that in turn propagates it to all MIH Users that have registered for this event. This is also shown in Figure The parameters are: Link ID MIH_Link_Detected This primitive indicates that a link that currently has no association with a base station has detected a base station to which a handover / attachment procedure could be performed. Note: This primitive could be triggered by receiving Layer 2 beacons from a base station. The event is generated at the link, sent to the MIHF that in turn propagates it to all MIH Users that have registered for this event. This is also shown in Figure The parameters are: Link ID MIH_Link_Actions This primitive can be used by a MIH User to issue commands to a specific link. The possible link command parameters are: Power Up Power Down Perform Handover Power Up activates a link such that layer 2 messages (e.g. beacons) can be retrieved. The link should not perform any base station attachment procedures on its own! Power Down shuts down a link, that is, the layer 2 association is closed by a detachment procedure and the link does not retrieve any layer 2 messages (e.g. beacons) anymore. Specification of the End-To-End ATM Network Simulator Page: 10-4

90 Perform Handover can only be issued on a link that is in state powered up. The link will then try to establish an association to a base station. The command is generated at the MIH User, sent to the MIHF that in turn sends it to the respective link. This is also shown in Figure The parameters are: Link ID, Command ID Figure 10-3 MIHF Command propagation Event & Command IDs The primitives should use the following IDs: 1 (MIH_)Link_Going_Down 2 (MIH_)Link_Down 3 (MIH_)Link_Detected 4 (MIH_)Link_Actions The command parameter IDs are as follows: 1 Power Up 2 Power Down 3 Perform Handover 10.2 RFC 4861: Neighbor Discovery for IP version 6 (IPv6) The following text copies parts from the original specification RFC 4861, taken form [13], with their original sub-section numbering and internal references. This specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. Specification of the End-To-End ATM Network Simulator Page: 10-5

91 Introduction This protocol solves a set of problems related to the interaction between nodes attached to the same link. It defines mechanisms for solving each of the following problems: Router Discovery: How hosts locate routers that reside on an attached link. Prefix Discovery: How hosts discover the set of address prefixes that define which destinations are on-link for an attached link. (Nodes use prefixes to distinguish destinations that reside on-link from those only reachable through a router.) Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address. Next-hop determination: The algorithm for mapping an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next-hop can be a router or the destination itself. Neighbor Unreachability Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again. Duplicate Address Detection: How a node determines whether or not an address it wishes to use is already in use by another node. Neighbor Discovery defines four different ICMP packet types: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisements messages. The messages serve the following purpose: Router Solicitation: When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time. Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc. Neighbor Solicitation: Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection. Specification of the End-To-End ATM Network Simulator Page: 10-6

92 Neighbor Advertisement: A response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change. On multicast-capable links, each router periodically multicasts a Router Advertisement packet announcing its availability. A host receives Router Advertisements from all routers, building a list of default routers. Router Advertisements (and per-prefix flags) allow routers to inform hosts how to perform Address Autoconfiguration. Nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. Neighbor Solicitation messages are multicast to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast Neighbor Advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation. Note: This is also shown in Figure 10-4 below. Figure 10-4 Signalling: Address Resolution Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor Unreachability Detection uses confirmation from two sources. When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). When positive confirmation is not forthcoming through such "hints", a node sends unicast Neighbor Solicitation messages that solicit Neighbor Advertisements as reachability confirmation from the next hop. Note: For the implementation, NUD will be significantly simplified. It is assumed that access routers frequently multicast Router Advertisements. These advertisements will Specification of the End-To-End ATM Network Simulator Page: 10-7

93 then serve as indication for forward progress. Lack of advertisements will then trigger a Neighbor Solicitation. Note: This is also shown in Figure 10-5 below. Figure 10-5 Signalling: Neighbor Unreachability Detection Protocol Specification 4.1. Router Solicitation Message Format Note: The RS message has a size of 144 bits with all relevant options. Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly Type Code Checksum Reserved Options IP Fields: Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface. Destination Address Specification of the End-To-End ATM Network Simulator Page: 10-8

94 Typically the all-routers multicast address. ICMP Fields: Type 133 Valid Options: Source link-layer address The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses. Note: It is suggested to always include the Source link-layer address option Router Advertisement Message Format Note: The RA message has a size of 464 bits with all relevant options. Routers send out Router Advertisement messages periodically, or in response to Router Solicitations Type Code Checksum Cur Hop Limit M O Reserved Router Lifetime Reachable Time Retrans Timer Options IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address Specification of the End-To-End ATM Network Simulator Page: 10-9

95 Typically the Source Address of an invoking Router Solicitation or the allnodes multicast address. ICMP Fields: Type 134 Reachable Time 32-bit unsigned integer. The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm (see Section 7.3). A value of zero means unspecified (by this router). Note: Reachable time should be set in accordance to the delay on the wireless link of the access router that sends the RA. E.g., Reachable Time = 2 * One Way Delay Possible options: Note: These options should always be included Source link-layer address The link-layer address of the interface from which the Router Advertisement is sent. Only used on link layers that have addresses. Prefix Information These options specify the prefixes that are on-link and/or are used for stateless address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a host with multiple interfaces may not be able to choose the correct outgoing interface when sending traffic to its neighbors Neighbor Solicitation Message Format Note: The NS message has a size of 272 bits with all relevant options. Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor Specification of the End-To-End ATM Network Simulator Page: 10-10

96 Type Code Checksum Reserved Target Address Options IP Fields: Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress) the unspecified address. Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. ICMP Fields: Type 135 Target Address he IP address of the target of the solicitation. It MUST NOT be a multicast address. Possible options: Note: These options should always be included. Source link-layer address The link-layer address for the sender Neighbor Advertisement Message Format Specification of the End-To-End ATM Network Simulator Page: 10-11

97 Note: The NA message has a size of 275 bits with all relevant options. A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly Type Code Checksum R S O Reserved Target Address Options IP Fields: Source Address An address assigned to the interface from which the advertisement is sent. Destination Address For solicited advertisements, the Source Address of an invoking Neighbor Solicitation or, if the solicitation's Source Address is the unspecified address, the allnodes multicast address. For unsolicited advertisements typically the all-nodes multicast address. ICMP Fields: Type 136 S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements. Specification of the End-To-End ATM Network Simulator Page: 10-12

98 Target Address For solicited advertisements, the Target Address field in the Neighbor Solicitation message that prompted this advertisement. For an unsolicited advertisement, the address whose link-layer address has changed. The Target Address MUST NOT be a multicast address. Possible options: Note: The following option is always included. Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included on link layers that have addresses when responding to multicast solicitations. When responding to a unicast Neighbor Solicitation this option SHOULD be included Source/Target Link-layer Address Note: This option has a size of 80 bits Type Length Link-Layer Address Fields: Type 1 for Source Link-layer Address 2 for Target Link-layer Address Link-Layer Address The variable length link-layer address. Description The Source Link-Layer Address option contains the link-layer address of the sender of the packet. It is used in the Neighbor Solicitation, Router Solicitation, and Router Advertisement packets. Specification of the End-To-End ATM Network Simulator Page: 10-13

99 The Target Link-Layer Address option contains the link-layer address of the target. It is used in Neighbor Advertisement and Redirect packets. messages. These options MUST be silently ignored for other Neighbor Discovery Prefix Information Note: This option has a size of 256bits Type Length Prefix Length L A Reserved Valid Lifetime Preferred Lifetime Reserved Prefix Fields: Type 3 Length 4 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option). It also assists with address autoconfiguration as specified in [ADDRCONF], for which there may be more restrictions on the prefix length. Note: We use prefix lengths of 64. Specification of the End-To-End ATM Network Simulator Page: 10-14

100 L 1-bit on-link flag. When set, indicates that this prefix can be used for onlink determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link. Note: The on-link flag is always set to 1. A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [ADDRCONF]. Note: The autonomous address-configuration flag is always set to 1. Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. Description The Prefix Information option provides hosts with on-link prefixes and prefixes for Address Autoconfiguration. The Prefix Information option appears in Router Advertisement packets and MUST be silently ignored for other messages Conceptual Data Structures Hosts will need to maintain the following pieces of information for each interface: Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is a router or a host (called IsRouter in this document), a pointer to any queued packets waiting for address resolution to complete, etc. A Neighbor Cache entry also contains information used by the Neighbor Unreachability Detection algorithm, including the reachability state, the number of unanswered probes, and the time the next Neighbor Unreachability Detection event is scheduled to take place. Destination Cache - A set of entries about destinations to which traffic has been sent recently. The Destination Cache includes both on-link and off-link destinations and provides a level of indirection into the Neighbor Cache; the Destination Cache maps a destination IP address to the IP address of the next-hop neighbor. Implementations may find it convenient to store additional information not directly related to Neighbor Discovery in Specification of the End-To-End ATM Network Simulator Page: 10-15

101 Destination Cache entries, such as the Path MTU (PMTU) and round-trip timers maintained by transport protocols. Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement. The link-local prefix is considered to be on the prefix list with an infinite invalidation timer regardless of whether routers are advertising a prefix for it. Received Router Advertisements SHOULD NOT modify the invalidation timer for the link-local prefix. Note: The prefix list might best be integrated with the routing table. Default Router List - A list of routers to which packets may be sent. Router list entries point to entries in the Neighbor Cache; the algorithm for selecting a default router favors routers known to be reachable over those whose reachability is suspect. Each entry also has an associated invalidation timer value (extracted from Router Advertisements) used to delete entries that are no longer advertised. Note: It is assumed that only one default router will be used. Hence, this list is not required and the information can be stored in a single object. The Neighbor Cache contains information maintained by the Neighbor Unreachability Detection algorithm. INCOMPLETE Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. REACHABLE Roughly speaking, the neighbor is known to have been reachable recently (within tens of seconds ago). STALE The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability. DELAY The neighbor is no longer known to be reachable, and traffic has recently been sent to the neighbor. Rather than probe the neighbor immediately, however, delay Specification of the End-To-End ATM Network Simulator Page: 10-16

102 sending probes for a short while in order to give upper-layer protocols a chance to provide reachability confirmation. PROBE The neighbor is no longer known to be reachable, and unicast Neighbor Solicitation probes are being sent to verify reachability. Note: For now we will only use the states INCOMPLETE and REACHABLE Conceptual Sending Algorithm When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor. Next-hop determination for a given unicast destination operates as follows. The sender selects a router from the Default Router List. Note: There will always not be more than one Default Router for us. For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination computations are saved in the Destination Cache. When the sending node has a packet to send, it first examines the Destination Cache. If no entry exists for the destination, next-hop determination is invoked to create a Destination Cache entry. Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast- capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. Note: See Figure Each time a Neighbor Cache entry is accessed while transmitting a unicast packet, the sender checks Neighbor Unreachability Detection related information according to the Neighbor Unreachability Detection algorithm (Section 7.3). This unreachability check Specification of the End-To-End ATM Network Simulator Page: 10-17

103 might result in the sender transmitting a unicast Neighbor Solicitation to verify that the neighbor is still reachable. Note: See Figure Next-hop determination is done the first time traffic is sent to a destination. As long as subsequent communication to that destination proceeds successfully, the Destination Cache entry continues to be used. If at some point communication ceases to proceed, as determined by the Neighbor Unreachability Detection algorithm, next-hop determination may need to be performed again. Note: Next-hop determination will invoke Address Resolution. See Figure Note that when a node redoes next-hop determination there is no need to discard the complete Destination Cache entry. In fact, it is generally beneficial to retain such cached information as the PMTU and round-trip timer values that may also be kept in the Destination Cache entry. Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received. Note: This is also shown in Figure 10-6 below. Figure 10-6 Signalling: Router Discovery. Note: Timers should be set on a per-interface level Garbage Collection and Timeout Requirements From the perspective of correctness, there is no need to periodically purge Destination and Neighbor Cache entries. Although stale information can potentially remain in the Specification of the End-To-End ATM Network Simulator Page: 10-18

104 cache indefinitely, the Neighbor Unreachability Detection algorithm ensures that stale information is purged quickly if it is actually being used. When removing an entry from the Prefix List, there is no need to purge any entries from the Destination or Neighbor Caches. Neighbor Unreachability Detection will efficiently purge any entries in these caches that have become invalid. When removing an entry from the Default Router List, however, any entries in the Destination Cache that go through that router must perform next-hop determination again to select a new default router. Note: Instead of the Default Router List, if the Default Router object is updated, next-hop determination is initiated again for all Destination Cache entries. 6. Router and Prefix Discovery Routers send Router Advertisements that indicate whether the sender is willing to be a default router. Router Advertisements also contain Prefix Information options that list the set of prefixes that identify on-link IP addresses. Note: It is assumed that all access routers periodically send Router Advertisements in frequent intervals Message Validation Validation of Router Solicitation Messages Hosts MUST silently discard any received Router Solicitation Messages Router Specification Router Configuration Variables For each interface: IsRouter A flag indicating whether routing is enabled on this interface. Enabling routing on the interface would imply that a router can forward packets to or from the interface. MaxRtrAdvInterval The maximum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds. Default: 600 seconds Specification of the End-To-End ATM Network Simulator Page: 10-19

105 MinRtrAdvInterval The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 3 seconds and no greater than.75 * MaxRtrAdvInterval. Default: 0.33 * MaxRtrAdvInterval If MaxRtrAdvInterval >= 9 seconds; otherwise, the Default is MaxRtrAdvInterval. AdvPrefixList A list of prefixes to be placed in Prefix Information options in Router Advertisement messages sent from the interface. Default: all prefixes that the router advertises via routing protocols as being on-link for the interface from which the advertisement is sent. The link-local prefix SHOULD NOT be included in the list of advertised prefixes. Note: Instead of a list, we will only use a single (non link-local) prefix Becoming an Advertising Interface The term "advertising interface" refers to any functioning and enabled interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface. A router MUST join the all-routers multicast address on an advertising interface. Routers respond to Router Solicitations sent to the all-routers address and verify the consistency of Router Advertisements sent by neighboring routers. Note: For the implementation, routers can join the above mentioned multicast group without any dedicated signalling. It only has to be ensured that routers will receive messages that have been sent to the those multicast groups Router Advertisement Message Content A router sends periodic Router Advertisements out its advertising interfaces. Outgoing Router Advertisements are filled with the following values consistent with the message format given in Section 4.2: - In the options: Specification of the End-To-End ATM Network Simulator Page: 10-20

106 o Source Link-Layer Address option: link-layer address of the sending interface. o Prefix Information options: one Prefix Information option for the prefix listed in AdvPrefixList with the option fields set from the information in the AdvPrefixList entry as follows: Note: It is assumed that every router will only advertise one prefix per interface. - In the "on-link" flag: the entry's AdvOnLinkFlag. - In the "Autonomous address configuration" flag: the entry's AdvAutonomousFlag. Note: This flag should always be set to true Sending Unsolicited Router Advertisements A host MUST NOT send Router Advertisement messages at any time. Unsolicited Router Advertisements are not strictly periodic: the interval between subsequent transmissions is randomized. Each advertising interface has its own timer. Whenever a multicast advertisement is sent from an interface, the timer is reset to a uniformly distributed random value between the interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; expiration of the timer causes the next advertisement to be sent and a new random value to be chosen Processing Router Solicitations A host MUST silently discard any received Router Solicitation messages. In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. In all cases, Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds. A router might process Router Solicitations as follows: - Schedule the sending of a Router Advertisement at the time given by the random value. Specification of the End-To-End ATM Network Simulator Page: 10-21

107 Router Solicitations in which the Source Address is the unspecified address MUST NOT update the router's Neighbor Cache; solicitations with a proper source address update the Neighbor Cache as follows. If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, then the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to REACHABLE. If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link- layer address and sets its reachability state to INCOMPLETE as specified in Section If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router responds with a unicast router advertisement. A Source Link-Layer Address option is provided Host Specification Host Variables These variables have default values that are overridden by information received in Router Advertisement messages. The default values are used when there is no router on the link or when all received Router Advertisements have left a particular value unspecified. For each interface: BaseReachableTime A base value used for computing the random ReachableTime value. Default: REACHABLE_TIME milliseconds. ReachableTime The time a neighbor is considered reachable after receiving a reachability confirmation. This value should be a uniformly distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times BaseReachableTime milliseconds. A new random value should be calculated when BaseReachableTime changes (due to Router Advertisements) Interface Initialization The host joins the all-nodes multicast address on all multicast-capable interfaces. Note: It is suggested to not implement multicast group membership. The signalling delay that will occur due to this functionality should be taken into account though. This delay corresponds to 1000ms. It is also applicable after every handover of the corresponding Specification of the End-To-End ATM Network Simulator Page: 10-22

108 interface of the node - more precisely, it should be the first operation after movement has been detected Processing Received Router Advertisements On receipt of a valid Router Advertisement, a host extracts the source address of the packet and does the following: - If the address is not already present in the host's Default Router List, and the advertisement's Router Lifetime is non-zero, create a new entry in the list. Note: This operation will indicate the presence of a new router and will therefore also trigger Neighbor Unreachability Detection. If the received Reachable Time value is non-zero, the host SHOULD set its BaseReachableTime variable to the received value. If the new value differs from the previous value, the host SHOULD re-compute a new random ReachableTime value. Note: Recomputation of ReachableTime might be omitted. ReachableTime is computed as a uniformly distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random component eliminates the possibility that Neighbor Unreachability Detection messages will synchronize with each other. The RetransTimer variable SHOULD be copied from the Retrans Timer field, if the received value is non-zero. If the advertisement contains a Source Link-Layer Address option, the link-layer address SHOULD be recorded in the Neighbor Cache entry for the router (creating an entry if necessary) and the IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If a Neighbor Cache entry is created for the router, its reachability state MUST be set to REACHABLE as specified in Section For each Prefix Information option with the on-link flag set, a host does the following: - If the prefix is not already present in the Prefix List, create a new entry for the prefix. Note: Only one prefix will be present Timing out Prefixes and Default Routers Specification of the End-To-End ATM Network Simulator Page: 10-23

109 No existing Destination Cache entries need be updated. Should a reachability problem arise with an existing Neighbor Cache entry, Neighbor Unreachability Detection will perform any needed recovery. Note: This is shown in Figure Whenever the Lifetime of an entry in the Default Router List expires, that entry is discarded. When removing a router from the Default Router list, the node MUST update the Destination Cache in such a way that all entries using the router perform next-hop determination again rather than continue sending traffic to the (deleted) router. Note: In this situation most likely no new router has been detected. Packets are then queued until a new default router has been detected Default Router Selection The algorithm for selecting a router depends in part on whether or not a router is known to be reachable. The exact details of how a node keeps track of a neighbor's reachability state are covered in Section 7.3. The algorithm for selecting a default router is invoked during next-hop determination when no Destination Cache entry exists for an off-link destination. Under normal conditions, a router would be selected the first time traffic is sent to a destination, with subsequent traffic for that destination using the same router as indicated in the Destination Cache. The policy for selecting routers from the Default Router List is as follows: 1) Routers that are reachable or probably reachable (i.e., in any state other than INCOMPLETE) SHOULD be preferred over routers whose reachability is unknown or suspect (i.e., in the INCOMPLETE state, or for which no Neighbor Cache entry exists). Note: As it is assumed that only one default router exists, this procedure should be significantly simplified. Hence, if the current router becomes unreachable the host should be able to create a new default router by processing the next Router Advertisement Sending Router Solicitations Note: It is suggested that access routers always send Router Advertisements in frequent intervals. A host sends Router Solicitations to the all-routers multicast address. The IP source address is set to either one of the interface's unicast addresses or the unspecified address. The Source Link-Layer Address option SHOULD be set to the host's link-layer address, if the IP source address is not the unspecified address. Specification of the End-To-End ATM Network Simulator Page: 10-24

110 Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. Hence, if a mobile node received link-layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link-layer hints, and it is outside the scope of this specification. Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Note: This process is shown in Figure Address Resolution and Neighbor Unreachability Detection 7.2. Address Resolution Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address (see Section 5.2). Address resolution is never performed on multicast addresses. Note: This is shown in Figure Note: It is assumed that no communication peer is on-link, except for the default router. Hence the procedure described above can be ignored Interface Initialization When a multicast-capable interface becomes enabled, the node MUST join the allnodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. Joining the solicited-node multicast address is done using a Multicast Listener Discovery protocols. Note: This operation should be skipped and simulated by a delay of 1000ms Sending Neighbor Solicitations Specification of the End-To-End ATM Network Simulator Page: 10-25

111 When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. If the solicitation is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option. While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. However, the number of queued packets per neighbor SHOULD be limited to some small value. When a queue overflows, the new arrival SHOULD replace the oldest entry. Once address resolution completes, the node transmits any queued packets. Note: This overall process is shown in Figure If the Source Address is not the unspecified address and the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation. Note: The Source Link-Layer Address option should always be included for the relevant messages. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to INCOMPLETE as specified in Section If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set to FALSE. If a Neighbor Cache entry already exists, its IsRouter flag MUST NOT be modified. After any updates to the Neighbor Cache, the node sends a Neighbor Advertisement response as described in the next section Sending Solicited Neighbor Advertisements A node sends a Neighbor Advertisement in response to a valid Neighbor Solicitation targeting one of the node's assigned addresses. The Target Address of the advertisement is copied from the Target Address of the solicitation. Furthermore, if the node is a router, it MUST set the Router flag to one; otherwise, it MUST set the flag to zero. If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation. Specification of the End-To-End ATM Network Simulator Page: 10-26

112 Receipt of Neighbor Advertisements When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE; otherwise, it is set to INCOMPLETE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution Neighbor Unreachability Detection Communication to or through a neighbor may fail for numerous reasons at any time. If the destination has failed, no recovery is possible and communication fails. On the other hand, if it is the path that has failed, recovery may be possible. Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets. Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols. When a path to a neighbor appears to be failing, the specific recovery procedure depends on how the neighbor is being used. If the neighbor is the ultimate destination, for example, address resolution should be performed again. If the neighbor is a router, however, attempting to switch to another router would be appropriate. The specific recovery that takes place is covered under next-hop determination; Neighbor Unreachability Detection signals the need for next-hop determination by deleting a Neighbor Cache entry. Neighbor Unreachability Detection is performed only for neighbors to which unicast packets are sent; it is not used when sending to multicast addresses. Note: This is shown in Figure Specification of the End-To-End ATM Network Simulator Page: 10-27

113 Reachability Confirmation A neighbor is considered reachable if the node has recently received a confirmation that packets sent recently to the neighbor werereceived by its IP layer. Positive confirmation can be gathered in two ways: hints from upper-layer protocols that indicate a connection is making "forward progress", or receipt of a Neighbor Advertisement message that is a response to a Neighbor Solicitation message. A connection makes "forward progress" if the packets received from a remote peer can only be arriving if recent packets sent to that peer are actually reaching it. In TCP, for example, receipt of a (new) acknowledgment indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgments are being delivered to the remote peer. If packets are reaching the peer, they must also be reaching the sender's next-hop neighbor; thus, "forward progress" is a confirmation that the next-hop neighbor is reachable. For off-link destinations, forward progress implies that the first-hop router is reachable. When available, this upper-layer information SHOULD be used. The receipt of a solicited Neighbor Advertisement serves as reachability confirmation, since advertisements with the Solicited flag set to one are sent only in response to a Neighbor Solicitation. Receipt of other Neighbor Discovery messages, such as Router Advertisements and Neighbor Advertisement with the Solicited flag set to zero, MUST NOT be treated as a reachability confirmation. Note: Contrary to the above paragraph, receipt of neighbor discovery messages (Router Advertisements) should be treated as reachability confirmation Neighbor Cache Entry States A Neighbor Cache entry can be in one of five states: INCOMPLETE Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received. REACHABLE Positive confirmation was received within the last ReachableTime milliseconds that the forward path to the neighbor was functioning properly. While REACHABLE, no special action takes place as packets are sent. STALE More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly. While stale, no action takes place until a packet is sent. Specification of the End-To-End ATM Network Simulator Page: 10-28

114 The STALE state is entered upon receiving an unsolicited Neighbor Discovery message that updates the cached link-layer address. Receipt of such a message does not confirm reachability, and entering the STALE state ensures reachability is verified quickly if the entry is actually being used. However, reachability is not actually verified until the entry is actually used. DELAY More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly, and a packet was sent within the last DELAY_FIRST_PROBE_TIME seconds. If no reachability confirmation is received within DELAY_FIRST_PROBE_TIME seconds of entering the DELAY state, send a Neighbor Solicitation and change the state to PROBE. The DELAY state is an optimization that gives upper-layer protocols additional time to provide reachability confirmation in those cases where ReachableTime milliseconds have passed since the last confirmation due to lack of recent traffic. Without this optimization, the opening of a TCP connection after a traffic lull would initiate probes even though the subsequent three-way handshake would provide a reachability confirmation almost immediately. PROBE A reachability confirmation is actively sought by retransmitting Neighbor Solicitations every RetransTimer milliseconds until a reachability confirmation is received Node Behavior When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. When a reachability confirmation is received (either through upper-layer advice or a solicited Neighbor Advertisement), an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer address is cached). Note: Router Advertisements can also change the state to REACHABLE. When ReachableTime milliseconds have passed since receipt of the last reachability confirmation for a neighbor, the Neighbor Cache entry's state changes from REACHABLE to INCOMPLETE. Note: An implementation may actually defer changing the state from REACHABLE to INCOMPLETE until a packet is sent to the neighbor, i.e., there need not be an explicit timeout event associated with the expiration of ReachableTime. Specification of the End-To-End ATM Network Simulator Page: 10-29

115 A Neighbor Cache entry enters the INCOMPLETE state when created as a result of receiving packets other than solicited Neighbor Advertisements In some cases, link-specific information may indicate that a path to a neighbor has failed (e.g., the resetting of a virtual circuit). In such cases, link-specific information may be used to purge Neighbor Cache entries before the Neighbor Unreachability Detection would do so. However, link-specific information MUST NOT be used to confirm the reachability of a neighbor; such information does not provide end-to-end confirmation between neighboring IP layers. 10. Protocol Constants Router constants: MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions MIN_DELAY_BETWEEN_RAS 3 seconds MAX_RA_DELAY_TIME.5 seconds Host constants: MAX_RTR_SOLICITATION_DELAY RTR_SOLICITATION_INTERVAL MAX_RTR_SOLICITATIONS 1 second 4 seconds 3 transmissions Node constants: MAX_MULTICAST_SOLICIT 3 transmissions MAX_UNICAST_SOLICIT 3 transmissions MAX_ANYCAST_DELAY_TIME 1 second MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions REACHABLE_TIME 30,000 milliseconds RETRANS_TIMER 1,000 milliseconds DELAY_FIRST_PROBE_TIME 5 seconds MIN_RANDOM_FACTOR.5 MAX_RANDOM_FACTOR IANA Considerations Specification of the End-To-End ATM Network Simulator Page: 10-30

116 Message name ICMPv6 Type Router Solicitation 133 Router Advertisement 134 Neighbor Solicitation 135 Neighbor Advertisement 136 Redirect 137 Option Name Type Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5 Appendix C: State Machine for the Reachability State When performing address resolution and Neighbor Unreachability Detection the following state transitions apply using the conceptual model: State Event Action New state - Packet to send. Create entry. INCOMPLETE Send multicast NS. Start retransmit timer INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE less than N Start retransmit retransmissions. timer INCOMPLETE Retransmit timeout, Discard entry - N or more Send ICMP error retransmissions. INCOMPLETE NA, Solicited=0, Record link-layer STALE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. INCOMPLETE NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag Link-layer address Specification of the End-To-End ATM Network Simulator Page: 10-31

117 - NS, RS, Redirect - - No link-layer address!incomplete NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached.!incomplete NA, Solicited=any, Update content of unchanged Override=any, No IsRouter flag. link-layer address REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached. STALE, PROBE NA, Solicited=1, - unchanged Or DELAY Override=0 Different link-layer address than cached.!incomplete NA, Solicited=1, Record link-layer REACHABLE Override=1 address (if different).!incomplete NA, Solicited=0, - unchanged Override=0!INCOMPLETE NA, Solicited=0, - unchanged Override=1 Same link-layer address as cached.!incomplete NA, Solicited=0, Record link-layer STALE Override=1 address. Different link-layer address than cached.!incomplete upper-layer reachability - REACHABLE confirmation REACHABLE timeout, more than - STALE N seconds since reachability confirm. STALE Sending packet Start delay timer DELAY DELAY Delay timeout Send unicast NS probe PROBE Start retransmit timer PROBE Retransmit timeout, Retransmit NS PROBE less than N retransmissions. Specification of the End-To-End ATM Network Simulator Page: 10-32

118 PROBE Retransmit timeout, Discard entry - N or more retransmissions. Note: It is assumed that the NCEs for all communication peers (except default routers) are derived from the NCE of the default router. The state transitions for receiving unsolicited information other than Neighbor Advertisement messages apply to either the source of the packet (for Neighbor Solicitation, Router Solicitation, and Router Advertisement messages) or the target address (for Redirect messages) as follows: State Event Action New state - NS, RA Create entry. INCOMPLETE INCOMPLETE NS, NA, RA Record link-layer REACHABLE address. Send queued packets.!incomplete NS, RA Update link-layer REACHABLE Different link-layer address address than cached. INCOMPLETE NS, RS No link-layer - unchanged address!incomplete NS, RS, RA, Redirect - unchanged Same link-layer address as cached RFC 4862: IPv6 Stateless Address Autoconfiguration The following text copies parts from the original specification RFC 4862, taken form [14], with their original sub-section numbering and internal references. This specification defines the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link Introduction The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by Specification of the End-To-End ATM Network Simulator Page: 10-33

119 combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. Note: The use case of link-local communication between nodes where one of the peers is not a router is not of interest for the implementation. IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding (and address) become invalid and the address may be reassigned to another interface elsewhere in the Internet. To handle the expiration of address bindings gracefully, an address goes through two distinct phases while assigned to an interface. Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted. Later, an address becomes "deprecated" in anticipation that its current interface binding will become invalid. While an address is in a deprecated state, its use is discouraged, but not strictly forbidden. New communication (e.g., the opening of a new TCP connection) should use a preferred address when possible. A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption. Note: Address lifetime will not be included. To ensure that all configured addresses are likely to be unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before assigning them to an interface. The Duplicate Address Detection algorithm is performed on all addresses, independently of whether they are obtained via stateless autoconfiguration or DHCPv6. This document defines the Duplicate Address Detection algorithm. The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface Protocol Specification Note: For the purpose of the simulations, it is assumed that routers are configured with unique addresses. 2. Terminology Specification of the End-To-End ATM Network Simulator Page: 10-34

120 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity. node - a device that implements IP. router - a node that forwards IP packets not explicitly addressed to itself. host - any node that is not a router. upper layer - a protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and Internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. The protocol described in this document will be used on all types of links unless specified otherwise in the link-typespecific document describing how to operate IP on the link in line with [RFC4861]. interface - a node's attachment to a link. packet - an IP header plus payload. address - an IP-layer identifier for an interface or a set of interfaces. unicast address - an identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. multicast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. anycast address - an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocol's measure of distance). solicited-node multicast address - a multicast address to which Neighbor Solicitation messages are sent. Specification of the End-To-End ATM Network Simulator Page: 10-35

121 link-layer address - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for Integrated Services Digital Network (ISDN) links. link-local address - an address having link-only scope that can be used to reach neighboring nodes attached to the same link. All interfaces have a link-local unicast address. global address - an address with unlimited scope. communication - any packet exchange among nodes that requires that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or a UDP request-response. tentative address - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the tentative address. interface identifier - a link-dependent identifier for an interface that is (at least) unique per link. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type. Note that the address architecture also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address. 4. Protocol Overview This section provides an overview of the typical steps that take place when an interface autoconfigures itself. Autoconfiguration is performed only on multicast-capable links and begins when a multicast-capable interface is enabled, e.g., during system startup. Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending an identifier of the interface to the well-known link-local prefix. Before the link-local address can be assigned to an interface and used, however, a node must attempt to verify that this "tentative" address is not already in use by another node on the link. Specifically, it sends a Neighbor Solicitation message containing the tentative address as the target. If another node is already using that address, it will return a Neighbor Advertisement saying so. If another node is also attempting to use the same address, it will send a Neighbor Solicitation for the target as well. The exact Specification of the End-To-End ATM Network Simulator Page: 10-36

122 number of times the Neighbor Solicitation is (re)transmitted and the delay time between consecutive solicitations is link-specific and may be set by system management. Note: The process of sending NS and NA messages to detect duplicates will be simplified. In fact, assuming that all nodes will always generate unique addresses, this signalling can be completely omitted for a simulation and only the incurred delays have to be taken into account. Once a node ascertains that its tentative link-local address is unique, it assigns the address to the interface. At this point, the node has IP-level connectivity with neighboring nodes. The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. Note: For mobile nodes, the next Step is actually the first step as we need a RA for movement detection. Note: DHCP is ignored for the purpose of the simulations. Router Advertisements contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. Note: RAs only contain a single prefix. Because routers generate Router Advertisements periodically, hosts will continually receive new advertisements. Hosts process the information contained in each advertisement, refreshing information received in previous advertisements. By default, all addresses should be tested for uniqueness prior to their assignment to an interface for safety. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration. 5. Protocol Specification Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. Specification of the End-To-End ATM Network Simulator Page: 10-37

123 Note: The router case is ignored; instead the procedure described below is only applicable to hosts Node Configuration Variables A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast-capable interface: DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. Default: 1 Autoconfiguration also assumes the presence of the variable RetransTimer. For autoconfiguration purposes, RetransTimer specifies the delay between consecutive Neighbor Solicitation transmissions performed during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1), as well as the time a node waits after sending the last Neighbor Solicitation before ending the Duplicate Address Detection process Creation of Link-Local Addresses A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events: - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks. A link-local address is formed by combining the well-known link-local prefix FE80::0 (of appropriate length) with an interface identifier as follows: 1. The left-most 'prefix length' bits of the address are those of the link-local prefix. 2. The bits in the address to the right of the link-local prefix are set to all zeroes. 3. If the length of the interface identifier is N bits, the right-most N bits of the address are replaced by the interface identifier Duplicate Address Detection Specification of the End-To-End ATM Network Simulator Page: 10-38

124 Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface. - Each individual unicast address SHOULD be tested for uniqueness. Note: It is assumed that every host will have only one link-local and one global address per interface. After movement has been detected, DAD is performed for both addresses at the same time (in parallel). The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages as described below. An address on which the Duplicate Address Detection procedure is applied is said to be tentative until the procedure has completed successfully. Note: For as long as an address is tentative, packets destined to that interface have to be discarded. The only exceptions are Neighbor Discovery messages. Similarly, packets should not be sent over an interface that has only tentative addresses, except for ND messages Sending Neighbor Solicitation Messages Before sending a Neighbor Solicitation, an interface MUST join the all-nodes multicast address and the solicited-node multicast address of the tentative address. The former ensures that the node receives Neighbor Advertisements from other nodes already using the address; the latter ensures that two nodes attempting to use the same address simultaneously should detect each other's presence. To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. Note: The NS messages don t have to be sent. Only the delay will be taken into account. The node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY if the address being checked is configured by a router advertisement message sent to a multicast address. Note: The MLD report message does not have to be implemented for as long as the node can receive and send multicast packets. Only the delay is relevant. Specification of the End-To-End ATM Network Simulator Page: 10-39

125 In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address during the delay period Receiving Neighbor Solicitation Messages On receipt of a valid Neighbor Solicitation message on an interface, node behavior depends on whether or not the target address is tentative. If the target address is not tentative (i.e., it is assigned to the receiving interface), the solicitation is processed as described in [13] Creation of Global Addresses Global addresses are formed by appending an interface identifier to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements Router Advertisement Processing For each Prefix-Information option in the Router Advertisement: d) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical), and if the Valid Lifetime is not 0, form an address (and add it to the list) by combining the advertised prefix with an interface identifier of the link as follows: N bits N bits link prefix interface identifier If an address is formed successfully and the address is not yet in the list, the host adds it to the list of addresses assigned to the interface 10.4 RFC 3775: Mobility Support in IPv6 The following text copies parts from the original specification RFC 3775, taken form [9], with their original sub-section numbering and internal references. This specification defines a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with Specification of the End-To-End ATM Network Simulator Page: 10-40

126 its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes Introduction The protocol defined in this document, known as Mobile IPv6, allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. One can think of the Mobile IPv6 protocol as solving the network-layer mobility management problem. Some mobility management applications -- for example, handover among wireless transceivers, each of which covers only a very small geographic area -- have been solved using link-layer techniques. For example, in many current wireless LAN products, link-layer mobility mechanisms allow a "handover" of a mobile node from one cell to another, re-establishing link-layer connectivity to the node in each new location General Terms IP Internet Protocol Version 6 (IPv6). node A device that implements IP. router A node that forwards IP packets not explicitly addressed to itself. unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must have either a global or site-local scope (but not link-local). host Any node that is not a router. link Specification of the End-To-End ATM Network Simulator Page: 10-41

127 A communication facility or medium over which nodes can communicate at the link layer, such as an Ethernet (simple or bridged). A link is the layer immediately below IP. interface A node's attachment to a link. subnet prefix A bit string that consists of some number of initial bits of an IP address. interface identifier A number used to identify a node's interface on a link. The interface identifier is the remaining low-order bits in the node's IP address after the subnet prefix. link-layer address A link-layer identifier for an interface, such as IEEE 802 addresses on Ethernet links. packet An IP header plus payload. security association An IPsec security association is a cooperative relationship formed by the sharing of cryptographic keying material and associated context. Security associations are simplex. That is, two security associations are needed to protect bidirectional traffic between two nodes, one for each direction. security policy database A database that specifies what security services are to be offered to IP packets and in what fashion. destination option Destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers in between. Mobile IPv6 defines one new destination option, the Home Address destination option (see Section 6.3). routing header A routing header may be present as an IPv6 header extension, and indicates that the payload has to be delivered to a destination IPv6 address in some way that is different Specification of the End-To-End ATM Network Simulator Page: 10-42

128 from what would be carried out by standard Internet routing. In this document, use of the term "routing header" typically refers to use of a type 2 routing header, as specified in Section Mobile IPv6 Terms home address A unicast routable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Mobile nodes can have multiple home addresses, for instance when there are multiple home prefixes on the home link. home subnet prefix The IP subnet prefix corresponding to a mobile node's home address. home link The link on which a mobile node's home subnet prefix is defined. mobile node A node that can change its point of attachment from one link to another, while still being reachable via its home address. movement A change in a mobile node's point of attachment to the Internet such that it is no longer connected to the same link as it was previously. If a mobile node is not currently attached to its home link, the mobile node is said to be "away from home". L2 handover A process by which the mobile node changes from one link-layer connection to another. For example, a change of wireless access point is an L2 handover. L3 handover Subsequent to an L2 handover, a mobile node detects a change in an on-link subnet prefix that would require a change in the primary care-of address. For example, a change of access router subsequent to a change of wireless access point typically results in an L3 handover. correspondent node Specification of the End-To-End ATM Network Simulator Page: 10-43

129 A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. foreign subnet prefix Any IP subnet prefix other than the mobile node's home subnet prefix. foreign link Any link other than the mobile node's home link. care-of address A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple careof addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address. home agent A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. binding The association of the home address of a mobile node with a care-of address for that mobile node, along with the remaining lifetime of that association. registration The process during which a mobile node sends a Binding Update to its home agent or a correspondent node, causing a binding for the mobile node to be registered. mobility message A message containing a Mobility Header (see Section 6.1). correspondent registration A return routability procedure followed by a registration, run between the mobile node and a correspondent node. home registration Specification of the End-To-End ATM Network Simulator Page: 10-44

130 A registration between the mobile node and its home agent, authorized by the use of IPsec Protocol Specification 4. Overview of Mobile IPv Basic Operation A mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link, using conventional Internet routing mechanisms. While a mobile node is attached to some foreign link away from home, it is also addressable at one or more care-of addresses. A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless auto-configuration. As long as the mobile node stays in this location, packets addressed to this care-of address will be routed to the mobile node. The mobile node may also accept packets from several care-of addresses, such as when it is moving but still reachable at the previous link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message. Any node communicating with a mobile node is referred to in this document as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. There are two possible modes for communications between the mobile node and a correspondent node. The first mode, bidirectional tunneling, does not require Mobile IPv6 support from the correspondent node and is available even if the mobile node has not registered its current binding with the correspondent node. Packets from the correspondent node are routed to the home agent and then tunneled to the mobile node. Packets to the correspondent node are tunneled from the mobile node to the home agent ("reverse tunneled") and then routed normally from the home network to the correspondent node. In this mode, the home agent uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the mobile node's home address (or home addresses) on the home link. Each intercepted packet is tunneled to the mobile node's primary care-of address. This tunneling is performed using IPv6 encapsulation. Specification of the End-To-End ATM Network Simulator Page: 10-45

131 Note: Proxy Neighbor Discovery is not supposed to be used within the implementation. Instead it is assumed that the Home Agent is a border router that receives packets by means of normal routing. The second mode, "route optimization", requires the mobile node to register its current binding at the correspondent node. Packets from the correspondent node can be routed directly to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header [11] (see Section 6.4) to route the packet to the mobile node by way of the care-of address indicated in this binding. Note: Route Optimization will not be considered for the purpose of implementing this RFC New IPv6 Protocol IPv6 defines a new Mobile IPv6 protocol, using the Mobility Header (see Section 6.1). This Header is used to carry the following messages: Binding Update A Binding Update is used by a mobile node to notify a correspondent node or the mobile node's home agent of its current binding. The Binding Update sent to the mobile node's home agent to register its primary care-of address is marked as a "home registration". Binding Acknowledgement A Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update, the binding update was sent to a home agent, or an error occurred Conceptual Data Structure Terminology This document describes the Mobile IPv6 protocol in terms of the following conceptual data structures: Binding Cache A cache of bindings for other nodes. This cache is maintained by home agents and correspondent nodes. The cache contains both "correspondent registration" entries (see Section 9.1) and "home registration" entries (see Section 10.1). Note: Again, within the scope of this RFC, correspondent registrations will not be considered for the implementation. Specification of the End-To-End ATM Network Simulator Page: 10-46

132 Binding Update List This list is maintained by each mobile node. The list has an item for every binding that the mobile node has or is trying to establish with a specific other node. Both correspondent and home registrations are included in this list. Entries from the list are deleted as the lifetime of the binding expires. See Section New IPv6 Protocol, Message Types, and Destination Option 6.1. Mobility Header The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The subsections within this section describe the message types that may be sent using the Mobility Header. Note: For the purpose of the implementation in the simulator, the Mobility Header does not have to be implemented as an extension header. Instead, it can be carried as payload of an IP packet. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section and the Binding Update List check described in Section which are normally performed for all packets Format The Mobility Header is identified by a Next Header value of 135 in the immediately preceding header, and has the following format: Payload Proto Header Len MH Type Reserved Checksum Message Data MH Type Specification of the End-To-End ATM Network Simulator Page: 10-47

133 8-bit selector. Identifies the particular mobility message in question. Current values are specified in Section and onward. An unrecognized MH Type field causes an error indication to be sent. Message Data A variable length field containing the data specific to the indicated Mobility Header type. Mobile IPv6 also defines a number of "mobility options" for use within these messages; if included, any options MUST appear after the fixed portion of the message data specified in this document. Note: For the ease of implementation, Options can be implemented as hardcoded variables. They are ignored if their values are set to NULL Binding Update Message Note: The BU that is sent to the Home Agent has a size of 32 bytes, including all headers, options, etc. The Binding Update (BU) message is used by a mobile node to notify other nodes of a new care-of address for itself. Binding Updates are sent as described in Section and Section The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Sequence # A H L K Reserved Lifetime Mobility options Acknowledge (A) The Acknowledge (A) bit is set by the sending mobile node to request a Binding Acknowledgement (Section 6.1.8) be returned upon receipt of the Binding Update. Specification of the End-To-End ATM Network Simulator Page: 10-48

134 Note: The A bit can be skipped, but it has to be ensured that all nodes that legitimately receive a BU respond with a BA. Home Registration (H) The Home Registration (H) bit is set by the sending mobile node to request that the receiving node should act as this node's home agent. The destination of the packet carrying this message MUST be that of a router sharing the same subnet prefix as the home address of the mobile node in the binding. Sequence # A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. Note: The Source Address field of the BU will always be used as CoA Binding Acknowledgement Message Note: The BA that is sent from the Home Agent to the Mobile Node has a size of 12 bytes, including all headers, options, etc. The Binding Acknowledgement is used to acknowledge receipt of a Binding Update (Section 6.1.7). This packet is sent as described in Section and Section The Binding Acknowledgement has the MH Type value 6. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Status K Reserved Sequence # Lifetime Mobility options... Specification of the End-To-End ATM Network Simulator Page: 10-49

135 Status 8-bit unsigned integer indicating the disposition of the Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following Status values are currently defined: 0 Binding Update accepted 135 Sequence number out of window Note: For the purpose of the implementation of this RFC, only the status number 0 has to be implemented. This field can therefore be completely skipped then. However, it should be possible to include it later on with other protocol extensions. Sequence # The Sequence Number in the Binding Acknowledgement is copied from the Sequence Number field in the Binding Update. It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update Home Address Option Note: For ease of implementation, the HoA Option can be skipped and the HoA itself be represented as a field within the BU. The BU size defined above already takes this into account. The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address. The Home Address option is encoded in type-length-value (TLV) format as follows: Option Type Option Length Home Address Specification of the End-To-End ATM Network Simulator Page: 10-50

136 Home Address The home address of the mobile node sending the packet. This address MUST be a unicast routable address. 7. Modifications to IPv6 Neighbor Discovery 7.3. New Advertisement Interval Option Format Mobile IPv6 defines a new Advertisement Interval option, used in Router Advertisement messages to advertise the interval at which the sending router sends unsolicited multicast Router Advertisements. The format of the Advertisement Interval option is as follows: Type Length Reserved Advertisement Interval Note: The Advertisement Interval Option can be used by Mobile Nodes to detect the lack of new RAs and therefore the unreachability of the default router. This option should however only be used by access routers that serve wireless links! In case the option is used, the size of a RA as specified in [13] is increased by 64 bits. Advertisement Interval 32-bit unsigned integer. The maximum time, in milliseconds, between successive unsolicited Router Advertisement messages sent by this router on this network interface. Using the conceptual router configuration variables defined by Neighbor Discovery [13], this field MUST be equal to the value MaxRtrAdvInterval, expressed in milliseconds Changes to Sending Router Advertisements The Neighbor Discovery protocol specification [13] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages from any given network interface (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: "Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection." Specification of the End-To-End ATM Network Simulator Page: 10-51

137 This limitation, however, is not suitable to providing timely movement detection for mobile nodes. Mobile nodes detect their own movement by learning the presence of new routers as the mobile node moves into wireless transmission range of them (or physically connects to a new wired network), and by learning that previous routers are no longer reachable. Mobile nodes MUST be able to quickly detect when they move to a link served by a new router, so that they can acquire a new care-of address and send Binding Updates to register this care-of address with their home agent and to notify correspondent nodes as needed. One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are: o MinRtrAdvInterval 0.03 seconds o MaxRtrAdvInterval 0.07 seconds Note: The MinRtrAdvInterval should be adjusted to 1 second and the MaxRtrAdvInterval should be adjusted to 2 seconds. In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast router advertisements is 50 ms. Use of these modified limits MUST be configurable. Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section Note: As specified in the description of RFC 4861 [13], the SLLAO should be included in all RAs anyway. 8. Requirements for Types of IPv6 Nodes 8.3. All IPv6 Routers All IPv6 routers, even those not serving as a home agent for Mobile IPv6, have an effect on how well mobile nodes can communicate: Specification of the End-To-End ATM Network Simulator Page: 10-52

138 o Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. If the router supports a faster rate, the used rate MUST be configurable. o Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2). Note: As already discussed for RFC 4861 [13], every router will advertise only one prefix per interface IPv6 Home Agents In order for a mobile node to operate correctly while away from home, at least one IPv6 router on the mobile node's home link must function as a home agent for the mobile node. The following additional requirements apply to all IPv6 routers that serve as a home agent: o Every home agent MUST be able to intercept packets addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section ). Note: HAs will not use proxy NDP to intercept packets. Instead they function as routers that receive packets by normal routing protocol operation. o Every home agent MUST be able to encapsulate such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section ). o Every home agent MUST support decapsulating reverse tunnelled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunnelled packets corresponds to the currently registered location of the mobile node (Section ). o The node MUST be able to process Mobility Headers as described in Section o Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section ) IPv6 Mobile Nodes Finally, the following requirements apply to all IPv6 nodes capable of functioning as mobile nodes: Specification of the End-To-End ATM Network Simulator Page: 10-53

139 o The node MUST maintain a Binding Update List (Section 11.1). o The node MUST be able to perform IPv6 encapsulation and decapsulation. o The node MUST support movement detection, care-of address formation, and returning home (Section 11.5). o The node MUST be able to process Mobility Headers as described in Section o The node MUST be able to send Binding Updates, as specified in Section and Section o The node MUST be able to receive and process Binding Acknowledgements, as specified in Section Correspondent Node Operation Note: CN operation is not relevant for the implementation of this RFC. However, as the HA Operation section references several of the CN sections, they are kept in place. This is due to the fact that HAs and CNs share a certain degree of functionality Conceptual Data Structures A separate Binding Cache SHOULD be maintained by each IPv6 node for each of its unicast routable addresses. The Binding Cache MAY be implemented in any manner consistent with the external behavior described in this document, for example by being combined with the node's Destination Cache as maintained by Neighbor Discovery [12]. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache. Each Binding Cache entry conceptually contains the following fields: o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent. o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. o A flag indicating whether or not this Binding Cache entry is a home registration entry (applicable only on nodes which support home agent functionality). Specification of the End-To-End ATM Network Simulator Page: 10-54

140 o The maximum value of the Sequence Number field received in previous Binding Updates for this home address. The Sequence Number field is 16 bits long. Sequence Number values MUST be compared modulo 2**16 as explained in Section The Binding Cache for any one of a node's IPv6 addresses may contain at most one entry for each mobile node home address. The contents of a node's Binding Cache MUST NOT be changed in response to a Home Address option in a received packet Receiving Binding Updates Before accepting a Binding Update, the receiving node MUST validate the Binding Update according to the following tests: o The Sequence Number field in the Binding Update is greater than the Sequence Number received in the previous valid Binding Update for this home address, if any. If the receiving node has no Binding Cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. This Sequence Number comparison MUST be performed modulo 2**16, i.e., the number is a free running counter represented modulo A Sequence Number in a received Binding Update is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as through 65535, would be considered less than or equal. Note: The following pseudo-code specifies when a binding is rejected or accepted: if ( ((bcseqnumber % 65536) > buseqnumber) OR (( bcseqnumber) % < buseqnumber) ) reject BU; else accept BU; If the mobile node sends a sequence number which is not greater than the sequence number from the last valid Binding Update for this home address, then the receiving node MUST send back a Binding Acknowledgement with status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement. Specification of the End-To-End ATM Network Simulator Page: 10-55

141 Note: The functionality of responding with a BA with a status code does not have to be implemented for this RFC, but must be supported for future protocol extensions. If the Binding Update is valid according to the test above, then the Binding Update is processed further as follows: o The Sequence Number value received from a mobile node in a Binding Update is stored by the receiving node in its Binding Cache entry for the given home address. o If the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address. The Binding Update is processed according to the procedure specified in Section The specified care-of address MUST be determined as follows: o The care-of address is the Source Address field in the packet's IPv6 header. The home address for the binding MUST be determined as follows: o If the Home Address destination option is present, the home address is the address in that option. Note: The HoA is specified in the appropriate field of the BU Sending Binding Acknowledgements If the node accepts the Binding Update and creates or updates an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. Otherwise, the Status field MUST be set to a value greater than or equal to 128. Values for the Status field are described in Section and in the IANA registry of assigned numbers [19]. Note: For the implementation of RFC 3775, the status field can be skipped. An acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. 10. Home Agent Operation Conceptual Data Structures Specification of the End-To-End ATM Network Simulator Page: 10-56

142 Each home agent MUST maintain a Binding Cache. The rules for maintaining a Binding Cache are the same for home agents and correspondent nodes and have already been described in Section Processing Bindings Primary Care-of Address Registration When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section Note: Home Agents accept bindings for as long as the Home Address to register is derived from the Home Network Prefix. If the source address of the BU is not the HoA, then this BU requests to register a primary CoA. If home agent accepts the Binding Update, it MUST then create a new entry in its Binding Cache for this mobile node or update its existing Binding Cache entry, if such an entry already exists. The Home Address field as received in the Home Address option provides the home address of the mobile node. The home agent MUST mark this Binding Cache entry as a home registration to indicate that the node is serving as a home agent for this binding. Unless this home agent already has a binding for the given home address, the home agent MUST perform Duplicate Address Detection [14] on the mobile node's home link before returning the Binding Acknowledgement. Note: DAD does not have to be performed in terms of exchanging signalling. Instead, it is sufficient to only take into account the delay generated by DAD. The details can be found in the description of RFC 4862 [14]. Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows: o The Status field MUST be set to a value indicating success. Note: Again, the Status field can be skipped. However, it should be possible to use it for a protocol extension at a later point in time. o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. Specification of the End-To-End ATM Network Simulator Page: 10-57

143 The rules for selecting the Destination IP address (and possibly routing header construction) for the Binding Acknowledgement to the mobile node are the same as in Section In addition, the home agent MUST follow the procedure defined in Section to intercept packets on the mobile node's home link addressed to the mobile node, while the home agent is serving as the home agent for this mobile node. Note: Packet interception is performed by routing and not by proxy NDP. The home agent MUST also be prepared to accept reverse tunneled packets from the new care-of address of the mobile node, as described in Section Note: For the tunnelling, headers at the HA are processed and constructed as follows: Inbound Packets from CN: Inner/Original IPv6 Header: Src=CN, Src=MN_HoA New Outer Header to prepend: Src=HA, Dest=MN_CoA Inbound Packets from MN: Original Header: Src=MN_CoA, Dest=HA, Src=MN_HoA, Dest=CN New, stripped header: Src=MN_HoA, Dest=CN Note: Adding an additional IPv6 header increases packet size by 40 bytes Primary Care-of Address De-Registration A binding may need to be de-registered when the mobile node returns home. A Binding Update is validated and authorized in the manner described in the previous section. Note: This refers to section The validation method itself is described in Section This section describes the processing of a valid Binding Update that requests the receiving node to no longer serve as its home agent, de-registering its primary care-of address. Note: A BU triggers deregistration if the source address of the BU corresponds to the HoA. Specification of the End-To-End ATM Network Simulator Page: 10-58

144 The home agent MUST delete any existing entry in its Binding Cache for this mobile node. Then, the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows: o The Status field MUST be set to a value 0, indicating success. Note: The Status field can be skipped. o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. In addition, the home agent MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section ). Note: For the implementation this means that the HA has to destroy the tunnel for this MN Packet Processing Intercepting Packets for a Mobile Node While a node is serving as the home agent for mobile node it MUST attempt to intercept packets on the mobile node's home link that are addressed to the mobile node. Note: As already mentioned previously, intercepting is achieved by the fact that the HA is a boundary router Processing Intercepted Packets For any packet sent to a mobile node from the mobile node's home agent (in which the home agent is the original sender of the packet), the home agent is operating as a correspondent node of the mobile node for this packet and the procedures described in Section apply. While the mobile node is away from home, the home agent intercepts any packets on the home link addressed to the mobile node's home address, as described in Section In order to forward each intercepted packet to the mobile node, the home agent MUST tunnel the packet to the mobile node using IPv6 encapsulation. When a home agent encapsulates an intercepted packet for forwarding to the mobile node, the home agent sets the Source Address in the new tunnel IP header to the home agent's own IP address and sets the Destination Address in the tunnel IP header to the mobile node's primary care-of address. When received by the mobile node, normal processing of the tunnel header will result in decapsulation and processing of the original packet by the mobile node. Specification of the End-To-End ATM Network Simulator Page: 10-59

145 Before tunneling a packet to the mobile node, the home agent MUST perform any IPsec processing as indicated by the security policy data base Handling Reverse Tunneled Packets Home agents MUST support reverse tunneling as follows: o The tunneled traffic arrives to the home agent's address using IPv6 encapsulation. o Depending on the security policies used by the home agent, reverse tunneled packets MAY be discarded unless accompanied by a valid ESP header. Note: This is subject to WP3.4/D15 specifications. o Otherwise, when a home agent decapsulates a tunneled packet from the mobile node, the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. This check is not necessary if the reversetunneled packet is protected by ESP in tunnel mode. 11. Mobile Node Operation Conceptual Data Structures Each mobile node MUST maintain a Binding Update List. The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address. Specification of the End-To-End ATM Network Simulator Page: 10-60

146 o The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 16 bits long and all comparisons between Sequence Number values MUST be performed modulo 2**16 (see Section 9.5.1). o The state of any retransmissions needed for this Binding Update. This state includes the time remaining until the next retransmission attempt for the Binding Update and the current state of the exponential back-off mechanism for retransmissions Packet Processing Sending Packets While Away from Home While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. When sending a packet while away from home, a mobile node MAY choose among these in selecting the address that it will use as the source of the packet, as follows: o Protocols layered over IP will generally treat the mobile node's home address as its IP address for most packets. For packets sent that are part of transport-level connections established while the mobile node was at home, the mobile node MUST use its home address. o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. The mobile node MUST NOT use the Home Address destination option for IPv6 Neighbor Discovery [13] packets. For packets sent by a mobile node while it is at home, no special Mobile IPv6 processing is required. Likewise, if the mobile node uses any address other than one of its home addresses as the source of a packet sent while away from home, no special Mobile IPv6 processing is required. In either case, the packet is simply addressed and transmitted in the same way as any normal IPv6 packet. For packets sent by the mobile node sent while away from home using the mobile node's home address as the source, special Mobile IPv6 processing of the packet is required. Reverse Tunneling This is the mechanism which tunnels the packets via the home agent. Specification of the End-To-End ATM Network Simulator Page: 10-61

147 This mechanism is used for packets that have the mobile node's home address as the Source Address in the IPv6 header. Specifically: * The packet is sent to the home agent using IPv6 encapsulation. * The Source Address in the tunnel packet is the primary care-of address as registered with the home agent. * The Destination Address in the tunnel packet is the home agent's address. Then, the home agent will pass the encapsulated packet to the correspondent node Receiving Packets While Away from Home While away from home, a mobile node will receive packets addressed to its home address, as follows: o Packets sent by a correspondent node, that does not have a Binding Cache entry for the mobile node, will be sent to the home address, captured by the home agent and tunneled to the mobile node. The mobile node MUST check that the IPv6 source address of the tunneled packet is the IP address of its home agent. The mobile node MUST also process the received packet in the manner defined for IPv6 encapsulation, which will result in the encapsulated (inner) packet being processed normally by upper-layer protocols within the mobile node as if it had been addressed (only) to the mobile node's home address Movement Movement Detection The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm which will function optimally for all types of applications, link-layers and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization, however it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance. When the mobile node detects an L3 handover, it selects a new default router and forms a new care-of address(es). Address Detection [13] is performed on its link-local Specification of the End-To-End ATM Network Simulator Page: 10-62

148 and new care-of address. It then registers its new primary care-of address with its home agent as described in Section Note: See also description of RFC Note: The overall signalling exchange (Movement Detection, DAD and BU/BA exchange) is shown in Figure Figure 10-7 Signalling: Movement Detection, DAD and BU/BA exchange Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes, if the mobile node detects that the currently selected default router on the old link is still bi-directionally reachable, it should generally continue to use the old router on the old link rather than switch away from it to use a new default router. Note: For the purpose of the implementation it can be assumed that advertisements from a new access router serve as indication that a new default router is available. The old default router can therefore be removed then if the RA was received on the same interface as the RAs of the old default router. The mobile node should consider the following events as indications that an L3 handover may have occurred. o Neighbor Unreachability Detection determines that the default router is no longer reachable Forming New Care-of Addresses After detecting that it has moved a mobile node SHOULD generate a new primary careof address using normal IPv6 mechanisms. A mobile node can have only one primary care-of address at a time (which is registered with its home agent), but it MAY have an additional care-of address for any or all of the prefixes on its current link. Specification of the End-To-End ATM Network Simulator Page: 10-63

149 Using Multiple Care-of Addresses A mobile node MAY use more than one care-of address at a time. Particularly in the case of many wireless networks, a mobile node effectively might be reachable through multiple links at the same time (e.g., with overlapping wireless cells), on which different on-link subnet prefixes may exist. The mobile node MUST ensure that its primary care-of address always has a prefix that is advertised by its current default router. After selecting a new primary care-of address, the mobile node MUST send a Binding Update containing that care-of address to its home agent. The Binding Update MUST have the Home Registration (H) bit set its home agent, as described on Section To assist with smooth handovers, a mobile node SHOULD retain its previous primary care-of address as a (non-primary) care-of address, and SHOULD still accept packets at this address, even after registering its new primary care-of address with its home agent. This is reasonable, since the mobile node could only receive packets at its previous primary care-of address if it were indeed still connected to that link. Whenever a mobile node determines that it is no longer reachable through a given link, it SHOULD invalidate all care-of addresses associated with address prefixes that it discovered from routers on the unreachable link which are not in the current set of address prefixes advertised by the (possibly new) current default router Returning Home A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section ), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set Home Registration (H) bit and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update. The mobile node then sends its Binding Update to the home agent's address, instructing its home agent to no longer serve as a home agent for it. By processing this Binding Update, the home agent will cease defending the mobile node's home address. The mobile node is then the only node on the link receiving packets at the mobile node's home address. In addition, when returning home prior to the expiration of a current binding for its home address, and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address. After the Mobile Node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations for its home address. Such replies MUST be sent using a unicast Neighbor Advertisement to the sender's link-layer address. Specification of the End-To-End ATM Network Simulator Page: 10-64

150 Note that the tunnel via the home agent typically stops operating at the same time that the home registration is deleted Processing Bindings Sending Binding Updates to the Home Agent After deciding to change its primary care-of address as described in Section and Section , a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. To register a care-of address the mobile node sends a packet to its home agent containing a Binding Update, with the packet constructed as follows: o The Home Registration (H) bit MUST be set in the Binding Update. o The Acknowledge (A) bit MUST be set in the Binding Update. Note: The A bit can be skipped for as long as BAs are always returned implicitly. o The packet MUST contain a Home Address destination option, giving the mobile node's home address for the binding. Note: The HoA Option can be skipped and instead the HoA be stored in a field of the BU. o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header. When sending a Binding Update to its home agent, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section The last Sequence Number value sent to the home agent in a Binding Update is stored by the mobile node. If the sending mobile node has no knowledge of the correct Sequence Number value, it may start at any value. Note: It is recommended to start with a sequence number of 0 ( zero ) Receiving Binding Acknowledgements Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: Specification of the End-To-End ATM Network Simulator Page: 10-65

151 o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. Any Binding Acknowledgement not satisfying this test MUST be silently ignored. When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows: o If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged; the mobile node MUST then stop retransmitting the Binding Update. Note: For the purpose of the implementation of this RFC, the status field can be skipped. However, it should be possible to use it later on for a protocol extension Retransmissions and Rate Limiting The mobile node is responsible for retransmissions and rate limiting in registrations. When the mobile node sends a Binding Update for which it expects a response, the mobile node has to determine a value for the initial retransmission timer: o If the mobile node is sending a Binding Update and does not have an existing binding at the home agent, it SHOULD use InitialBindackTimeoutFirstReg (see Section 13) as a value for the initial retransmission timer. This long retransmission interval will allow the home agent to complete the Duplicate Address Detection procedure mandated in this case, as detailed in Section o Otherwise, the mobile node should use the specified value of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer. If the mobile node fails to receive a valid matching response within the selected initial retransmission interval, the mobile node SHOULD retransmit the message until a response is received. The retransmissions by the mobile node MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely. Specification of the End-To-End ATM Network Simulator Page: 10-66

152 The mobile node SHOULD start a separate back-off process for different message types, different home addresses and different care-of addresses. Note: The implementation only has to ensure that timers are set per interface. Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. 12. Protocol Constants DHAAD_RETRIES INITIAL_BINDACK_TIMEOUT INITIAL_DHAAD_TIMEOUT INITIAL_SOLICIT_TIMER MAX_BINDACK_TIMEOUT MAX_NONCE_LIFETIME MAX_TOKEN_LIFETIME MAX_RR_BINDING_LIFETIME MAX_UPDATE_RATE PREFIX_ADV_RETRIES PREFIX_ADV_TIMEOUT 4 retransmissions 1 second 3 seconds 3 seconds 32 seconds 240 seconds 210 seconds 420 seconds 3 times 3 retransmissions 3 seconds 13. Protocol Configuration Variables MaxMobPfxAdvInterval Default: 86,400 seconds MinDelayBetweenRAs Default: 3 seconds, Min: 0.03 seconds MinMobPfxAdvInterval Default: 600 seconds InitialBindackTimeoutFirstReg Default: 1.5 seconds The default value for InitialBindackTimeoutFirstReg has been calculated as 1.5 times the default value of RetransTimer [13] times the default value of DupAddrDetectTransmits [14]. The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in [13]. This variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds. Specification of the End-To-End ATM Network Simulator Page: 10-67

153 14. IANA Considerations Note: This section is relevant for assigning unique header values. This document creates a new name space "Mobility Header Type", for the MH Type field in the Mobility Header. The current message types are described starting from Section 6.1.2, and are the following: 5 Binding Update 6 Binding Acknowledgement Finally, this document creates a third new name space "Status Code" for the Status field in the Binding Acknowledgement message. The current values are described in Section 6.1.8, and are the following: 0 Binding Update accepted 135 Sequence number out of window Bootstrapping Note: The problem of bootstrapping the Mobile Nodes, which is, providing them with all relevant mobility information, is not addressed within this RFC. The Mobile Node has to be configured with the following information: Address of Home Agent Home Network Prefix Home Address The simulation environment should initialize all Mobile Nodes with this information during the start up phase, prior to any protocol exchanges. It is further assumed that the Mobile Node will only have 1 HoA for ATS/AOC and 1 HoA for AAC/APC. Specification of the End-To-End ATM Network Simulator Page: 10-68

154 10.5 RFC 3963: NEMO The following text copies parts from the original specification RFC 3963, taken form [10], with their original sub-section numbering and internal references. This specification defines describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network Introduction This document describes protocol extensions to Mobile IPv6 (MIPv6) [9] to enable support for network mobility. The extensions are backward compatible with Mobile IPv6. In particular, a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent. The NEMO Basic Support ensures session continuity for all the nodes in the Mobile Network, even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the Mobile Network as it moves. The solution supports both mobile nodes and hosts that do not support mobility in the Mobile Network. Within the context of this document, the definition of a Mobile Router extends that of a Mobile IPv6 [9] Mobile Node, by adding routing capability routing between its point of attachment (Care-of Address) and a subnet that moves with the Mobile Router. The solution described in this document proposes a bi-directional tunnel between the Mobile Router and its Home Agent. This tunnel is set up when the Mobile Router sends a successful Binding Update to its Home Agent, informing the Home Agent of its current point of attachment. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not describe route optimization of this traffic. 2. Terminology This document in addition defines the following terms. Mobile Network Prefix An IPv6 prefix delegated to a Mobile Router and advertised in the Mobile Network. More than one Mobile Network Prefix could be advertised in a Mobile Network Protocol Specification 3. Overview of the NEMO Protocol A Mobile Network is a network segment or subnet that can move and attach to arbitrary points in the routing infrastructure. A Mobile Network can only be accessed via Specification of the End-To-End ATM Network Simulator Page: 10-69

155 specific gateways called Mobile Routers that manage its movement. Mobile Networks have at least one Mobile Router serving them. A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e., in the visited network). Instead, it maintains a bi-directional tunnel to a Home Agent that advertises an aggregation of Mobile Networks to the infrastructure. The Mobile Router is also the default gateway for the Mobile Network. A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router also advertises one or more prefixes in the Mobile Network attached to it. The actual mechanism for assigning these prefixes to a given Mobile Router is outside the scope of this specification. When the Mobile Router moves away from the home link and attaches to a new access router, it acquires a Care-of Address from the visited link. As soon as the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent as described in [9]. When the Home Agent receives this Binding Update, it creates a cache entry binding the Mobile Router's Home Address to its Care-of Address at the current point of attachment. If the Mobile Router seeks to act as a Mobile Router and provide connectivity to nodes in the Mobile Network, it indicates this to the Home Agent by setting a flag (R) in the Binding Update. It MAY also include information about the Mobile Network Prefix in the Binding Update by using one of the modes described in section 5.2, so that the Home Agent can forward packets meant for nodes in the Mobile Network to the Mobile Router. A new Mobility Header Option for carrying prefix information is described in section 4.3. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all of these prefixes, it includes multiple prefix information options in a single Binding Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address. The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement to the Mobile Router. A positive acknowledgement with the Mobile Router Flag (R) set means that the Home Agent has set up forwarding for the Mobile Network. Once the binding process finishes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are the Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation. The Home Agent decapsulates this packet and forwards it to the Correspondent Node. When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet is routed to the Home Agent that currently has the binding for the Mobile Router. The Mobile Router's network prefix would be aggregated at the Home Agent, which would advertise the resulting aggregation. Alternatively, the Home Agent may receive the data packets destined to the Mobile Network by advertising routes to the Mobile Network Prefix. The actual mechanism by which these routes are advertised is outside the scope of this document. When the Home Agent receives a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router's current Care-of Address. The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected. Before decapsulating the tunneled packet, the Mobile Router has to check whether the Source address on the outer IPv6 header is the Home Specification of the End-To-End ATM Network Simulator Page: 10-70

156 Agent's address. This check is not necessary if the packet is protected by IPsec in tunnel mode. The Mobile Router also has to make sure that the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet to the Mobile Network. If it does not, the Mobile Router should drop the packet. Note: The implementation can be simplified by classifying the Mobile Router as a Mobile Host. The fact that end systems are attached to the Mobile Router can be emulated by an appropriate number of applications that reside directly within the Mobile Router. The LAN on-board the aircraft does not have to be simulated then, therefore reducing computational overhead. No differences will occur for the implementation, as the mobility related signalling still takes the NEMO overhead into account. 4. Message Formats 4.1. Binding Update A new flag (R) is included in the Binding Update to indicate to the Home Agent whether the Binding Update is coming from a Mobile Router and not from a mobile node. The rest of the Binding Update format remains the same as defined in [9] Sequence # A H L K M R Reserved Lifetime Mobile Router Flag (R) The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, and it MUST NOT forward packets destined for the Mobile Network to the Mobile Router. Note: The R flag can be skipped Binding Acknowledgement A new flag (R) is included in the Binding Acknowledgement to indicate that the Home Agent that processed the corresponding Binding Update supports Mobile Routers. The flag is set only if the corresponding Binding Update had the Mobile Router Flag (R) set to 1. The rest of the Binding Acknowledgement format remains the same, as defined in [9] Specification of the End-To-End ATM Network Simulator Page: 10-71

157 Status K R Reserved Sequence # Lifetime Mobile Router Flag (R) The Mobile Router Flag is set to indicate that the Home Agent that processed the Binding Update supports Mobile Routers. It is set to 1 only if the corresponding Binding Update had the Mobile Router Flag set to 1. Note: The R flag can be skipped Mobile Network Prefix Option Note: The size of the MNP option is 160 bits. The Mobile Network Prefix Option is included in the Binding Update to indicate the prefix information for the Mobile Network to the Home Agent. There could be multiple Mobile Network Prefix Options if the Mobile Router has more than one IPv6 prefix in the Mobile Network and wants the Home Agent to forward packets for each of these prefixes to the Mobile Router's current location. The Mobile Network Prefix Option format is as follows Type Length Reserved Prefix Length Mobile Network Prefix Prefix Length Eight-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Specification of the End-To-End ATM Network Simulator Page: 10-72

158 Mobile Network Prefix A sixteen-byte field containing the Mobile Network Prefix Note: The MNP Option can be hardcoded into the BU. The BU size then has to be increased by [size of MNP option] times the number of MNPs. The option itself does not have to carry any useful information if the MR behaviour is that of a mobile host as in RFC 3775 [9]. Note: For the remainder of this specification, it is assumed that a MR is emulated as a Mobile Host. 5. Mobile Router Operation Mobile Router operation is derived from that of a Mobile Node [9]. Note: Operation is equal to that of RFC 3775 [9]. Only the BU size has to be increased to take the MNP options into account. 6. Home Agent Operation For a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in section 8.4 of [9]. Note: Operation is equal to that of RFC 3775 [9] Draft: Global HA to HA The protocol has draft status and is described in [11]. Parts of the paper [15] also discuss how a HA to HA protocol network can look like most parts of the description is based on this paper, as the draft [11] does not provide enough detail for an implementation as of now Introduction The Global HA to HA protocol [11] has been devised to provide some extent of route optimization support for NEMO. The starting point of its development was the observation that the binding of the MR to a single fixed HA, regardless of its relative location, is in general not a satisfactory solution. With regard to the network performance the suboptimal routing path of MRs in great distance from their HAs causes unnecessarily high latencies on the end-to-end path. Consequently, the solution envisaged by Global HA-to- HA relies on a distributed HA architecture that allows the MR to bind with its topologically closest HA. This feature is supported by the Dynamic Home Agent Address Discovery (DHAAD) procedure defined in MIPv6 using IPv6 anycast addressing. The introduction of a distributed solution helps overcoming the single point of failure of the (single) HA approach and offers a nearly optimized route between the Mobile Network and the Specification of the End-To-End ATM Network Simulator Page: 10-73

159 Correspondent Nodes. It is noteworthy that this distributed approach does not prevent the introduction of additional route optimization procedures to benefit from a fully bidirectional optimized route. In addition, the approach is open to protocol extensions addressing the specific needs of nested networks issue with several levels of MRs. The architecture makes use of another type of proxy, similar but different from the one defined by PMIPv6. This new type of proxy acts simultaneously as a classical HA from the MR point of view, and as a MR for the primary HA located in the MRs home network that manages and usually advertises the MRs reachability and route to the external network (i.e. to the Internet). Therefore, a binding for a MR attached to a foreign network is always performed in two separate steps: first the MR binds to the closest proxy HA, which in turns binds to the MR s primary HA. The deployment of this architecture is accomplished by means of an overlay network constituted of bidirectional tunnels. These are between primary HAs (possibly belonging to different network providers), and between primary and proxy HAs within the same network provider infrastructure. These tunnels are organized prior to any transmission of data from and to the MR and are expected to remain relatively during the lifetime of the MRs network attachment Overview As shown in Figure 10-8, we are assuming two subnetwork domains A and B. Both are part of the same service provider network (called the Extended Home Network), with each one HA (domain A with HA A and domain B with HA B) connected to each other via VPN tunnels. For example it is possible for a service provider to have different subnetwork domains on different continents. In addition, we have a Home Agent that is the primary HA (labeled HA C) for the MRs in question. It is located in a third subnet within the same operational domain as the other two subnetwork entities and is fully meshed within the Extended Home Network. From now on we call the HA of the MR the primary HA (priha) and all other HAs (potential) proxy HAs (proha) of the MR. MRs must have addresses configured from prefixes that are topologically anchored at one of the HAs. A MR always has a single primary HA whereas every other HA can serve as proxy HA. In our scenario that is depicted in Figure 10-8, HA C is the primary HA for the MR A that is currently attached to a foreign network and performs home registration registration as defined in NEMO [10]. All HAs of the three example subnets announce their common /32 prefix (corresponding to the Extended Home Network) via an Exterior Gateway Protocol (EGP) to the Internet, although in reality they only manage a local /36 prefix. Therefore, depending on the location of the MRs and CNs, traffic will be routed to the topologically closest HA. Incoming traffic not destined to the local /36 managed by the receiving HA has to be rerouted to the correct subnet that is the topological anchor for this prefix. For this reason, in addition the HAs must have configured routes and tunnels between themselves. That is, e.g., HA B must advertise a route for its own /36 to the other HAs via an Interior Gateway Protocol (IGP). Because of this, HAs advertising /32 prefixes to the Internet can forward packets to the correct /36 prefix owner (HA) internally. This scenario conforms to a specific type of distributed home network called partitioned home network. In the following the protocol is explained on these assumptions with regard to the network structure. Specification of the End-To-End ATM Network Simulator Page: 10-74

160 Figure 10-8 Global HA to HA network structure MR Registration In this section we will focus on the scenario of MR A being attached to a foreign domain Y (cf. Figure 10-8). The MR uses mobility signalling as defined in [10]. We start the discussion of this case considering how the MR can locate the closest HA. In the second step we show how the mobility signalling between the MR and the HA is performed. Finally we will discuss how the routing to and from the MR works inside the Extended Home Network and how it can be improved Locating appropriate HA The first step is to identify a mechanism that allows the MR to locate a HA that is suitable for a binding. From the RO perspective this means that the HA should be topologically close to the MR. The Dynamic Home Agent Address Discovery (DHAAD) mechanism specified in [9] can be used to locate a suitable home agent. The current specification of DHAAD is based on /64 home network prefixes and therefore limited to discovering HAs on the physical home link. In addition it requires that the MN is preconfigured with the home prefix. Using DHAAD in our case would require modifying the ICMP Home Agent Address Discovery Request message. The modification would be required to allow sending the message to the Mobile IPv6 Home Agents anycast address, constructed with a prefix that corresponds to the /32 extended home network instead of the /64 home subnet prefix (shown in Figure 10-8). All Home Agents have to be configured with this common 32-bit Specification of the End-To-End ATM Network Simulator Page: 10-75

161 anycast address on one of their interfaces that can be used to route traffic to the closest Home Agent. The Request-Response signalling is shown in Figure Figure 10-9 DHAAD signalling. The DHAAD Request Message is specified as follows: The ICMP Home Agent Address Discovery Request message is used by a mobile node to initiate the dynamic home agent address discovery mechanism. The mobile node sends the Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address for its own home subnet prefix Type Code Checksum Reserved Type Code Identifier An identifier to aid in matching Home Agent Address Discovery Reply messages to this Home Agent Address Discovery Request message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. The Source Address of the Home Agent Address Discovery Request Specification of the End-To-End ATM Network Simulator Page: 10-76

162 message packet is typically one of the mobile node's current care-of addresses. At the time of performing this dynamic home agent address discovery procedure, it is likely that the mobile node is not registered with any home agent. Therefore, neither the nature of the address nor the identity of the mobile node can be established at this time. The home agent MUST then return the Home Agent Address Discovery Reply message directly to the Source Address chosen by the mobile node. Instead of sending the message to the /64 home subnet prefix, it will be sent, as already explained above, to the prefix that corresponds to the Extended Home Network. Note: The DHAAD request message has a size of 64 bits. The DHAAD Reply Message is specified as follows: The ICMP Home Agent Address Discovery Reply message is used by a home agent to respond to a mobile node that uses the dynamic home agent address discovery mechanism Type Code Checksum Reserved Home Agent Addresses Type Code Identifier The identifier from the invoking Home Agent Address Discovery Request message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Home Agent Addresses Specification of the End-To-End ATM Network Simulator Page: 10-77

163 A list of addresses of home agents on the home link for the mobile node. The number of addresses presented in the list is indicated by the remaining length of the IPv6 packet carrying the Home Agent Address Discovery Reply message. The Source Address of the Home Agent Address Discovery Request message packet is typically one of the mobile node's current care-of addresses. At the time of performing this dynamic home agent address discovery procedure, it is likely that the mobile node is not registered with any home agent. Therefore, neither the nature of the address nor the identity of the mobile node can be established at this time. The home agent MUST then return the Home Agent Address Discovery Reply message directly to the Source Address chosen by the mobile node. Note: The DHAAD Reply Message has a size of 32 + n * 128 bits, where n corresponds to the number of listed Home Agents. It is recommended to list only one Home Agent per reply MR binding to HA Assuming that the MR is able to locate a suitable LMA, it is necessary to detect whether this responding HA is a primary (priha) or a proxy (proha). It is assumed that the address of the priha is known to the MR, e.g. it can be obtained by a bootstrapping mechanism. Based on this information, the MR can determine whether it is connected to the primary HA or a proxy HA. If the MR locates the priha as the closest MR, the Binding Update (BU) is constructed and sent to the address of the priha as specified in [10]. If the closest HA is a proha, the MR extends its BU by adding the address of its primary Home Agent. This allows the proha to associate the MR with its priha that is the topological anchor. Without this additional option HAs would require a database that maps MRs to their prihas. This database would even have to be integrated with the bootstrapping mechanism and other mechanisms that allow a MR to switch its Home Agent and therefore perform renumbering. Note: The size of Binding Updates that are sent to prohas is increased by 160 bits due to the priha Address Option Basic HA operation Upon receiving a BU from the MR, the HA checks whether it is the prhma of this MR. This is accomplished by comparing the Home Address (HoA) of the MR with the prefix(es) the HA serves. In case the MR sent the BU to its priha, the binding is considered primary and subsequent operations are not different from [10]. If the BU is sent to a proha, the binding is secondary. In this case the HA creates an appropriate entry in its binding cache. To allow differentiation between standard bindings and the proxy bindings, we add an Extended Proxy flag whose value is set to 1. Besides this, the binding cache entry at the proha is set up as specified in [10]. However, an Specification of the End-To-End ATM Network Simulator Page: 10-78

164 additional field is added that contains the address of the MRs primary HA, as learned through the additional information that the MR included in its BU HA to HA Synchronization If a HA receives a BU from a MR for which it will act as a proxy (because it is not the primary HA for this MR), it has to inform the priha that it currently proxies the MR. The proha sends an extended Proxy Binding Update (epbu) to the address of the priha. The differentiation between original BUs and the new epbus is achieved by an Extended Proxy Registration Flag E to indicate that this PBU is between a proha and a priha. The priha stores all the information from the epbu within its binding cache, including an extended proxy registration flag and the proha address for forwarding traffic destined to the MR/MNP to the proha that proxies the MR. The proha will only create a binding cache entry and return a valid Binding Acknowledgement (BA) to the MR if the priha returns an Extended Proxy Binding Acknowledgement (epba) indicating success as a response to the preceding epbu. It is important for the priha to only consider the most recent binding updates (from the MR) and extended proxy binding updates (from prohas) and to ignore outdated BUs or epbus. To achieve this goal the sequence numbers within the Binding Updates [10] are reused by the HA: the sequence number from the MRs BU is copied into the newly constructed epbu. This way, the priha can check which binding update is the most recent one and discard the others. In case the binding cache of the priha indicates that another proha is currently proxying the MR and the priha receives a valid BU from the MR or an epbu from another proha it updates its binding cache with this new binding and informs the old proha that it should delete its binding with the MR (if the sequence number in the new binding is higher than the one stored in the binding cache of the priha). As of now, the proha that currently proxies the MR has an appropriate binding cache entry and the priha of the MR knows with which proha the MR has a secondary binding with. The only remaining issue is forwarding of traffic within the Extended Home Network from and to the MR. The MR tunnels its data to the HA it currently has a binding with. In case of a primary binding (the HA is the priha) operation is not different from [12]. If it is a secondary binding (HA is a proha) then traffic is tunneled to this proha. The proha does not forward packets to the priha but instead directly routes the traffic to its destination, depending on the available IGP or EGP routes. As all HAs are announcing the /32 prefix via EGP (cf. Figure 1), traffic from the CNs to the MR/MNP can be attracted by any of the HAs. In general, the HA closest to the CN will usually receive all the traffic. Hence, the following three cases for traffic forwarding are possible. Case 1: traffic arrives at the current proha: As the MR has a secondary binding with this HA, it can directly tunnel the traffic to the MR itself. Case 2: traffic arrives at the priha: If the MR has a primary binding with the priha, then traffic can be directly tunneled to the MR. If the MR has a secondary binding with a proha, then priha forwards the traffic to this proha the address of the proha was Specification of the End-To-End ATM Network Simulator Page: 10-79

165 learned from the epbu that the proha sent to the priha in the course of the synchronization process. Case 3: traffic arrives at a HA that is neither primary nor a proxy (MR has no binding with this HA): The HA does not know anything about the MR but is informed of the priha that advertises an aggregate prefix via IGP (cf. Section 3.2) to which the MR/MNP belongs to. Hence the HA can forward the traffic to the priha which in turn knows of the current point of attachment of the MR (case 1 or 2 apply for further processing) In the last case (3), the fully meshed structure of the partitioned subnetwork domains allows routing the traffic destined for the MR to the primary HA that announces the /36 subnet prefix aggregating the HoA/MNP of the MR. This is a kind of default route if no binding cache entries are available for a certain destination. Mobility signalling and forwarding of user data for this case is shown in Figure The synchronization time between the different HAs is significantly influenced by their distances between each other. A large round-trip time also implies large delay for the transmission of epbu and epba. As long as this delay is smaller then the values defined for the retransmission timers for the BUs at the MR, this should not become a problem though. Figure Signalling for and traffic forwarding after HA synchronization Proactive Synchronization The synchronization mechanism in the previous section only covers signalling between the priha and prohas that have secondary bindings for the MR. Other HAs that might attract traffic from CNs destined to the MR/MNP will send these datagrams first to the priha (because of the default /36 routes) that in turn sends it directly to the MR or to the current proha (Case 2 from above), depending on the MRs current point of attachment. In the latter case the path is not optimal as shown in Figure 2 (CN HA priha proha - MR). This problem can be solved by a proactive approach. In the proactive synchronization strategy, a proha receives a BU from the MR and sends an epbu to the priha, just as before. However, during the final step when the priha sends the (positive) epba to the proha, the priha also sends epbus to all the other HAs in the Extended Home Network. These epbus contain HoA and MNP of the MR as well as the address of the proha that currently proxies the MR. Specification of the End-To-End ATM Network Simulator Page: 10-80

166 A HA upon receiving such an epbu creates an appropriate binding cache entry just like in and tunnels the traffic destined to the MR/MNP to the proha as learned from the epbu. This is shown in Figure Figure Proactive RO between LMAs. Note: It is suggested for the implementation to perform Proactive Synchronization per default RFC 5213: Proxy Mobile IPv6 The following text copies parts from the original specification RFC 5213, taken form [12], with their original sub-section numbering and internal references. Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signalling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signalling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv Introduction All the general mobility-related terms used within the PMIPv6 description are to be interpreted as defined in the Mobile IPv6 base specification [9]. This document adopts the terms, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG). This document also provides the following context-specific explanation to the following terms used in this document. Proxy Mobile IPv6 Domain (PMIPv6-Domain) Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile Specification of the End-To-End ATM Network Simulator Page: 10-81

167 access gateways between which security associations can be set up and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured. Local Mobility Anchor (LMA) Local Mobility Anchor is the home agent for the mobile node in a Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix(es) and is the entity that manages the mobile node's binding state. The local mobility anchor has the functional capabilities of a home agent as defined in Mobile IPv6 base specification [RFC3775] with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this specification. Mobile Access Gateway (MAG) Mobile Access Gateway is a function on an access router that manages the mobilityrelated signalling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signalling the mobile node's local mobility anchor. Mobile Node (MN) Throughout this document, the term mobile node is used to refer to an IP host or router whose mobility is managed by the network. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node and is not required to participate in any IP mobility related signaling for achieving mobility for an IP address that is obtained in that Proxy Mobile IPv6 domain. LMA Address (LMAA) The global address that is configured on the interface of the local mobility anchor and is the transport endpoint of the bi-directional tunnel established between the local mobility anchor and the mobile access gateway. This is the address to which the mobile access gateway sends the Proxy Binding Update messages. Proxy Care-of Address (Proxy-CoA) Proxy-CoA is the global address configured on the egress interface of the mobile access gateway and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway. The local mobility anchor views this address as the care-of address of the mobile node and registers it in the Binding Cache entry for that mobile node. Mobile Node's Home Network Prefix (MN-HNP) The MN-HNP is a prefix assigned to the link between the mobile node and the mobile access gateway. More than one prefix can be assigned to the link between the mobile node and the mobile access gateway, in which case, all of the assigned prefixes are managed as a set associated with a mobility session. The mobile node configures its interface with one or more addresses from its home network prefix(es). If the mobile Specification of the End-To-End ATM Network Simulator Page: 10-82

168 node connects to the Proxy Mobile IPv6 domain through multiple interfaces, simultaneously, each of the attached interfaces will be assigned a unique set of home network prefixes, and all the prefixes assigned to a given interface of a mobile node will be managed under one mobility session. For example, home network prefixes P1 and P2 assigned to interface I1 will be managed under one mobility session and prefixes P3, P4, and P5 assigned to interface I2 of the mobile node will be managed under a different mobility session. Additionally, in some configurations the assigned prefix can be of 128-bit prefix length. Mobile Node's Home Address (MN-HoA) MN-HoA is an address from a mobile node's home network prefix. The mobile node will be able to use this address as long as it is attached to the access network that is in the scope of that Proxy Mobile IPv6 domain. If the mobile node uses more than one address from its home network prefix(es), any one of these addresses is referred to as mobile node's home address. Unlike in Mobile IPv6 where the home agent is aware of the home address of the mobile node, in Proxy Mobile IPv6, the mobility entities are only aware of the mobile node's home network prefix(es) and are not always aware of the exact address(es) that the mobile node configured on its interface from its home network prefix(es). However, in some configurations and based on the enabled address configuration modes on the access link, the mobility entities in the network can be certain about the exact address(es) configured by the mobile node. Multihomed Mobile Node A mobile node that connects to the same Proxy Mobile IPv6 domain through more than one interface and uses these interfaces simultaneously is referred to as a multihomed mobile node. Mobile Node Identifier (MN-Identifier) The identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. This is typically an identifier such as a Network Access Identifier (NAI) or other identifier such as a Media Access Control (MAC) address. Mobile Node Link-layer Identifier (MN-LL-Identifier) An identifier that identifies the attached interface of a mobile node. For those interfaces that have a link-layer identifier, this identifier can be based on that. The linklayer identifier, in some cases, is generated by the mobile node and conveyed to the mobile access gateway. This identifier of the attached interface must be stable, as seen by any of the mobile access gateways in a given Proxy Mobile IPv6 domain. In some other cases, there might not be any link-layer identifier associated with the mobile node's interface. An identifier value of ALL_ZERO is not considered a valid identifier and cannot be used as an interface identifier. Proxy Binding Update (PBU) Specification of the End-To-End ATM Network Simulator Page: 10-83

169 A request message sent by a mobile access gateway to a mobile node's local mobility anchor for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address (Proxy- CoA). Proxy Binding Acknowledgement (PBA) A reply message sent by a local mobility anchor in response to a Proxy Binding Update message that it received from a mobile access gateway. Per-MN-Prefix and Shared-Prefix Models The term Per-MN-Prefix model is used to refer to an addressing model where there is a unique network prefix or prefixes assigned for each node. The term Shared-Prefix model is used to refer to an addressing model where the prefix(es) are shared by more than one node. This specification supports the Per-MN-Prefix model and does not support the Shared-Prefix model. Note: For the implementation in a simulation environment, it is valid to have a sharedprefix model. All issues related to this topic that are solved by adopting a per-mn prefix model can be ignored. Mobility Session In the context of Proxy Mobile IPv6 specification, the term mobility session refers to the creation or existence of state associated with the mobile node's mobility binding on the local mobility anchor and on the serving mobile access gateway. ALL_ZERO and NON_ZERO Protocol message fields initialized with value 0 in each byte of the field. For example, an 8-byte link-layer identifier field with the value set to 0 in each of the 8 bytes, or an IPv6 address with the value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is used to refer to any value other than an ALL_ZERO value. 3. Proxy Mobile IPv6 Protocol Overview Proxy Mobile IPv6 protocol is intended for providing network-based IP mobility management support to a mobile node, without requiring the participation of the mobile node in any IP mobility related signalling. The mobility entities in the network will track the mobile node's movements and will initiate the mobility signalling and set up the required routing state. The core functional entities in the NETLMM infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The local mobility anchor is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix(es). The mobile access gateway is the entity that performs the mobility management on behalf of a mobile node, and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements to and from the access link and Specification of the End-To-End ATM Network Simulator Page: 10-84

170 for initiating binding registrations to the mobile node's local mobility anchor. There can be multiple local mobility anchors in a Proxy Mobile IPv6 domain each serving a different group of mobile nodes. The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. Figure 1: Proxy Mobile IPv6 Domain When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access link, the mobile access gateway on that access link, after identifying the mobile node and acquiring its identity, will determine if the mobile node is authorized for the networkbased mobility management service. If the network determines that the mobile node is authorized for network-based mobility service, the network will ensure that the mobile node using any of the address configuration mechanisms permitted by the network will be able to obtain the address configuration on the connected interface and move anywhere in that Proxy Mobile IPv6 domain. The obtained address configuration includes the address(es) from its home network prefix(es), the default-router address on the link, and other related configuration parameters. From the perspective of each mobile node, the entire Proxy Mobile IPv6 domain appears as a single link, the network ensures that the mobile node does not detect any change with respect to its layer-3 attachment even after changing its point of attachment in the network. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack (IPv4/v6) node. Based on the policy profile information that indicates the type of address or Specification of the End-To-End ATM Network Simulator Page: 10-85

171 prefixes to be assigned for the mobile node in the network, the mobile node will be able to obtain an IPv4, IPv6, or dual IPv4/IPv6 address and move anywhere in that Proxy Mobile IPv6 domain. However, this specification only supports IPv6 address/prefix mobility with the transport network being IPv6. Note: This specification assumes IPv6 only networks. If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces and over multiple access networks, the network will allocate a unique set of home network prefixes for each of the connected interfaces. The mobile node will be able to configure address(es) on those interfaces from the respective home network prefix(es). However, if the mobile node performs a handoff by moving its address configuration from one interface to the other, and if the local mobility anchor receives a handoff hint from the serving mobile access gateway about the same, the local mobility anchor will assign the same home network prefix(es) that it previously assigned prior to the handoff. The mobile node will also be able to perform a handoff by changing its point of attachment from one mobile access gateway to a different mobile access gateway using the same interface and will be able to retain the address configuration on the attached interface. Figure 2: Mobile Node Attachment - Signaling Call Flow Figure 2 shows the signalling call flow when the mobile node enters the Proxy Mobile IPv6 domain. The Router Solicitation message from the mobile node may arrive at any Specification of the End-To-End ATM Network Simulator Page: 10-86

172 time after the mobile node's attachment and has no strict ordering relation with the other messages in the call flow. For updating the local mobility anchor about the current location of the mobile node, the mobile access gateway sends a Proxy Binding Update message to the mobile node's local mobility anchor. Upon accepting this Proxy Binding Update message, the local mobility anchor sends a Proxy Binding Acknowledgement message including the mobile node's home network prefix(es). It also creates the Binding Cache entry and sets up its endpoint of the bi-directional tunnel to the mobile access gateway. The mobile access gateway on receiving the Proxy Binding Acknowledgement message sets up its endpoint of the bi-directional tunnel to the local mobility anchor and also sets up the forwarding for the mobile node's traffic. At this point, the mobile access gateway has all the required information for emulating the mobile node's home link. It sends Router Advertisement messages to the mobile node on the access link advertising the mobile node's home network prefix(es) as the hosted on-link prefix(es). The mobile node, on receiving these Router Advertisement messages on the access link, attempts to configure its interface using either stateful or stateless address configuration modes, based on the modes that are permitted on that access link as indicated in Router Advertisement messages. At the end of a successful address configuration procedure, the mobile node has one or more addresses from its home network prefix(es). After address configuration, the mobile node has one or more valid addresses from its home network prefix(es) at the current point of attachment. The serving mobile access gateway and the local mobility anchor also have proper routing states for handling the traffic sent to and from the mobile node using any one or more of the addresses from its home network prefix(es). The local mobility anchor, being the topological anchor point for the mobile node's home network prefix(es), receives any packets that are sent to the mobile node by any node in or outside the Proxy Mobile IPv6 domain. The local mobility anchor forwards these received packets to the mobile access gateway through the bi-directional tunnel. The mobile access gateway on other end of the tunnel, after receiving the packet, removes the outer header and forwards the packet on the access link to the mobile node. However, in some cases, the traffic sent from a correspondent node that is locally connected to the mobile access gateway may not be received by the local mobility anchor and may be routed locally by the mobile access gateway. The mobile access gateway acts as the default router on the point-to-point link shared with the mobile node. Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and will be sent to its local mobility anchor through the bi-directional tunnel. The local mobility anchor on the other end of the tunnel, after receiving the packet, removes the outer header and routes the packet to the destination. However, in some cases, the traffic sent to a correspondent node that is locally connected to the mobile access gateway may be locally routed by the mobile access gateway. After obtaining the initial address configuration in the Proxy Mobile IPv6 domain, if the mobile node changes its point of attachment, the mobile access gateway on the previous link will detect the mobile node's detachment from the link. It will signal the local mobility anchor and will remove the binding and routing state for that mobile node. The local mobility anchor, upon receiving this request, will identify the corresponding mobility session for which the request was received, and accepts the request after which it waits for a certain amount of time to allow the mobile access gateway on the new link to update the binding. However, if it does not receive any Proxy Binding Update message Specification of the End-To-End ATM Network Simulator Page: 10-87

173 within the given amount of time, it will delete the binding cache entry. The mobile access gateway on the new access link, upon detecting the mobile node on its access link, will signal the local mobility anchor to update the binding state. After completion of the signalling, the serving mobile access gateway will send the Router Advertisements containing the mobile node's home network prefix(es), and this will ensure the mobile node will not detect any change with respect to the layer-3 attachment of its interface Protocol specification 5. Local Mobility Anchor Operation 5.1. Extensions to Binding Cache Entry Data Structure Every local mobility anchor MUST maintain a Binding Cache entry for each currently registered mobile node. A Binding Cache entry is a conceptual data structure, described in [9]. For supporting this specification, the Binding Cache Entry data structure needs to be extended with the following additional fields. A flag indicating whether or not this Binding Cache entry is created due to a proxy registration. This flag is set to value 1 for Binding Cache entries that are proxy registrations and is set to value 0 for all other entries. The identifier of the registered mobile node, MN-Identifier. This identifier is obtained from a Mobile Node Identifier Option present in the received Proxy Binding Update message. The link-layer identifier of the mobile node's connected interface on the access link. This identifier can be acquired from the Mobile Node Link-layer Identifier option, present in the received Proxy Binding Update message. A list of IPv6 home network prefixes assigned to the mobile node's connected interface. Each one of these prefix entries will also include the corresponding prefix length. The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation. 5.3 Signalling Considerations This section provides the rules for processing the signalling messages. The processing rules specified in this section and other related sections are chained and are in a specific order. When applying these considerations for processing the signalling messages, the specified order MUST be maintained Processing Proxy Binding Updates Note: First three items skipped. Specification of the End-To-End ATM Network Simulator Page: 10-88

174 4. The local mobility anchor MUST identify the mobile node from the identifier present in the Mobile Node Identifier option of the Proxy Binding Update message. If the Mobile Node Identifier option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to MISSING_MN_IDENTIFIER_OPTION (Missing Mobile Node Identifier option) and the identifier in the Mobile Node Identifier option carried in the message MUST be set to a zero length identifier. Note: If the implementation guarantees that a MN Identifier Option is always attached, this check can be skipped. Note: Items 5-8 skipped. 9. The local mobility anchor MUST apply the considerations specified in Section 5.5 for processing the Timestamp option in the Proxy Binding Update message. 10. If there is no Home Network Prefix option(s) (with any value) present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing Home Network Prefix option). Note: If the implementation guarantees that a Home Network Prefix Option is always attached, this check can be skipped. Note: Items skipped. 13. Considerations specified in Section MUST be applied for performing the Binding Cache entry existence test. If those checks specified in Section result in associating the received Proxy Binding Update message to a new mobility session creation request, considerations from Section (Initial Binding Registration - New Mobility Session), MUST be applied. If those checks result in associating the request to an existing mobility session, the following checks determine the next set of processing rules that need to be applied. * If the received Proxy Binding Update message has the lifetime value of zero, considerations from Section (Binding De- Registration) MUST be applied. * If the Proxy-CoA in the Binding Cache entry matches the source address of the request, considerations from Section (Binding Lifetime Extension - No handoff) MUST be applied. * For all other cases, considerations from Section (Binding Lifetime Extension - After handoff) MUST be applied. 14. When sending the Proxy Binding Acknowledgement message with any Status field value, the message MUST be constructed as specified in Section Specification of the End-To-End ATM Network Simulator Page: 10-89

175 Initial Binding Registration (New Mobility Session) Note: Items 1-3 skipped. 4. Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for the mobile node. It must set the fields in the Binding Cache entry to the accepted values for that registration. 5. If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST establish a bi-directional tunnel to that mobile access gateway. Considerations from Section MUST be applied for managing the dynamically created bi-directional tunnel. 6. The local mobility anchor MUST create a prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with this mobility session. The created tunnel and the routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section Note: This tunnel should be created as a host route, that is, a /128 entry is created in the routing table. In case of NEMO, the MNP of the MN can be used to set up to the forwarding state. 7. The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section Binding Lifetime Extension (No Handoff) 1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from the same mobile access gateway (if the Proxy-CoA in the Binding Cache entry is the same as the Proxy-CoA in the request) that last updated the binding, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values. 2. The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section Binding Lifetime Extension (After Handoff) 1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from a new mobile access gateway (if the Proxy-CoA in the Binding Specification of the End-To-End ATM Network Simulator Page: 10-90

176 Cache entry does not match the Proxy-CoA in the request) where the mobile node's mobility session is handed off, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values. 2. The local mobility anchor MUST remove the previously created route(s) for the mobile node's home network prefix(es) associated with this mobility session. Note: Item 3 skipped. 4. The local mobility anchor MUST create prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with that mobility session. The created tunnel and routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section Binding De-Registration 1. If the received Proxy Binding Update message with the lifetime value of zero has a Source Address in the IPv6 header different from what is present in the Proxy-CoA field in the Binding Cache entry, the local mobility anchor MUST ignore the request. 2. Upon accepting the Proxy Binding Update message, with the lifetime value of zero, the local mobility anchor MUST delete the Binding Cache entry and remove the routing state created for that mobility session. It MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section Constructing the Proxy Binding Acknowledgement Message o The local mobility anchor, when sending the Proxy Binding Acknowledgement message to the mobile access gateway, MUST construct the message as specified below. IPv6 header (src=lmaa, dst=proxy-coa) Mobility header - BA /* P flag must be set to value of 1 */ Mobility Options - Mobile Node Identifier option (mandatory) - Home Network Prefix option(s) (mandatory) - Access Technology Type option (mandatory) - Timestamp option (optional) Specification of the End-To-End ATM Network Simulator Page: 10-91

177 - Mobile Node Link-layer Identifier option (optional) - Link-local Address option (optional) Figure 6: Proxy Binding Acknowledgement Message Format Note: The size of the BU corresponds to the size of a home registration BU as specified in [9]. In addition, the following sizes have to be added for the Mobility Options: 304 bits for the MN Identifier Option, 160 bits for the Home Network option, 32 bits for the Access Technology Type option, 80 bits for the Timestamp option, 96 bits for the Mobile Node Link-layer Identifier option and 144 bits for the Link-local Address option. o The Source Address field in the IPv6 header of the message MUST be set to the destination address of the received Proxy Binding Update message. o The Destination Address field in the IPv6 header of the message MUST be set to the source address of the received Proxy Binding Update message. The destination address is the same as the Proxy-CoA. o The Mobile Node Identifier option MUST be present. The identifier field in the option MUST be copied from the Mobile Node Identifier option in the received Proxy Binding Update message. o One Home Network Prefix option MUST be present. o The Handoff Indicator option MUST be present. The handoff indicator field in the option MUST be copied from the Handoff Indicator option in the received Proxy Binding Update message. If the option was not present in the request, the value in the option MUST be set to zero. o The Timestamp option MUST be present. Considerations from Section 5.5 must be applied for constructing the Timestamp option. o The Mobile Node Link-layer Identifier option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. The link-layer identifier value MUST be copied from the Mobile Node Link-layer Identifier option present in the received Proxy Binding Update message. o The Link-local Address option MUST be present only if the same option was present in the received Proxy Binding Update message. * If the received Proxy Binding Update message has the Link-local Address option with NON_ZERO value, then the link-local address from the request MUST be copied to Specification of the End-To-End ATM Network Simulator Page: 10-92

178 the Link-local Address option in the reply. The same address MUST also be copied to the link-local address field of the Binding Cache entry associated with this request (after creating the Binding Cache entry, if one does not exist). o The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node. Typically, any one of the mobile node's home network prefixes from its mobility session may be used as a key for locating its Binding Cache entry in all cases except when there has been a handoff of the mobile node's session to a new mobile access gateway, and that mobile access gateway is unaware of the home network prefix(es) assigned to that mobility session Timestamp Option for Message Ordering Mobile IPv6 [9] uses the Sequence Number field in binding registration messages as a way for the home agent to process the binding updates in the order they were sent by a mobile node. The home agent and the mobile node are required to manage this counter over the lifetime of a binding. However, in Proxy Mobile IPv6, as the mobile node moves from one mobile access gateway to another and in the absence of mechanisms such as context transfer between the mobile access gateways, the serving mobile access gateway will be unable to determine the sequence number that it needs to use in the signalling messages. Hence, the sequence number scheme, as specified in [9], will be insufficient for Proxy Mobile IPv6. If the local mobility anchor cannot determine the sending order of the received Proxy Binding Update messages, it may potentially process an older message sent by a mobile access gateway where the mobile node was previously anchored, but delivered out of order, resulting in incorrectly updating the mobile node's Binding Cache entry and creating a routing state for tunneling the mobile node's traffic to the previous mobile access gateway. For solving this problem, this specification adopts an alternative solution based on timestamps. The basic principle behind the use of timestamps in binding registration messages is that the node generating the message inserts the current time of day, and the node receiving the message checks that this timestamp is greater than all previously accepted timestamps. Note: Timestamp should be present in every PBU and PBA. Using the Timestamp-Based Approach: 1. If the Timestamp option is present in the received Proxy Binding Update message, then the local mobility anchor MUST include a valid Timestamp option in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. Note: Items 2-4 skipped. Specification of the End-To-End ATM Network Simulator Page: 10-93

179 5. If the Timestamp option is present in the received Proxy Binding Update message, the local mobility anchor MUST ignore the sequence number field in the message. However, it MUST copy the sequence number from the received Proxy Binding Update message to the Proxy Binding Acknowledgement message. 6. Upon receipt of a Proxy Binding Update message with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the following MUST be true. * The timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node. 7. If the timestamp value in the received Proxy Binding Update is valid (validity as specified in the above considerations), the local mobility anchor MUST return the same timestamp value in the Timestamp option included in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. 8. If the timestamp value in the received Proxy Binding Update is lower than the previously accepted timestamp in the Proxy Binding Update messages sent for that mobility binding, the local mobility anchor MUST reject the Proxy Binding Update message and send a Proxy Binding Acknowledgement message with the Status field set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than previously accepted timestamp) Routing Considerations Bi-Directional Tunnel Management The bi-directional tunnel MUST be used for routing the mobile node's data traffic between the mobile access gateway and the local mobility anchor. A tunnel hides the topology and enables a mobile node to use address(es) from its home network prefix(es) from any access link in that Proxy Mobile IPv6 domain. Note: These tunnels can be pre-established and do not have to be dynamically established Forwarding Considerations Intercepting Packets Sent to the Mobile Node's Home Network: o When the local mobility anchor is serving a mobile node, it MUST be able to receive packets that are sent to the mobile node's home network. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's home network prefix(es) or for an aggregated prefix with a larger scope. This essentially enables IPv6 routers in that network to detect the local mobility anchor as the last-hop router for the mobile node's home network prefix(es). Note: As only a shared-prefix model is recommended for the implementation, a single /64 prefix can be advertised by the LMA. Specification of the End-To-End ATM Network Simulator Page: 10-94

180 Forwarding Packets to the Mobile Node: o On receiving a packet from a correspondent node with the destination address matching a mobile node's home network prefix(es), the local mobility anchor MUST forward the packet through the bi-directional tunnel set up for that mobile node. o The format of the tunneled packet is shown below. IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ Upper layer protocols /* Packet Content*/ Forwarding Packets Sent by the Mobile Node: o All the reverse tunneled packets that the local mobility anchor received from the mobile access gateway, after removing the tunnel header MUST be routed to the destination specified in the inner packet header. These routed packets will have the Source Address field set to the mobile node's home address. 6. Mobile Access Gateway Operation The Proxy Mobile IPv6 protocol described in this document introduces a new functional entity, the mobile access gateway (MAG). The mobile access gateway is the entity that is responsible for detecting the mobile node's movements to and from the access link and sending the Proxy Binding Update messages to the local mobility anchor. In essence, the mobile access gateway performs mobility management on behalf of a mobile node. The mobile access gateway is a function that typically runs on an access router. The mobile access gateway has the following key functional roles: o It is responsible for detecting the mobile node's movements on the access link and for initiating the mobility signalling with the mobile node's local mobility anchor. o Emulation of the mobile node's home link on the access link by sending Router Advertisement messages containing the mobile node's home network prefix(es), each prefix carried using the Prefix Information option [13]. o Responsible for setting up the forwarding for enabling the mobile node to configure one or more addresses from its home network prefix(es) and use it from the attached access link Extensions to Binding Update List Entry Data Structure Every mobile access gateway MUST maintain a Binding Update List. Each entry in the Binding Update List represents a mobile node's mobility binding with its local mobility Specification of the End-To-End ATM Network Simulator Page: 10-95

181 anchor. The Binding Update List is a conceptual data structure, described in Section 11.1 of [9]. For supporting this specification, the conceptual Binding Update List entry data structure needs be extended with the following additional fields. o The identifier of the attached mobile node, MN-Identifier. This identifier is acquired during the mobile node's attachment to the access link through mechanisms outside the scope of this document. o The link-layer identifier of the mobile node's connected interface. This can be acquired from the received Router Solicitation messages from the mobile node or during the mobile node's attachment to the access network. This is typically a link-layer identifier conveyed by the mobile node; however, the specific details on how that is conveyed is out of scope for this specification. Note: It is recommended that the link-layer identifier is equal to the MAC address of the MN. The MAC address itself can be made available by attaching this information it to the IP packet at the network interface/radio for reading at the PMIP implementation module. o A list of IPv6 home network prefixes assigned to the mobile node's connected interface. The home network prefix(es) have been statically configured in the mobile node's policy profile. Each of these prefix entries will also include the corresponding prefix length. Note: It is assumed that every MN exactly one pre-configured home network prefix. o The Link-local address of the mobile access gateway on the access link shared with the mobile node. o The IPv6 address of the local mobility anchor serving the attached mobile node. This address is acquired from the mobile node's policy profile or from other means. Note: It is recommended that the LMA address is equal to the address of the LMA that is connected to this MAG. o The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation. Note: It is assumed that tunnels are already pre-configured. Further, it is assumed that only one LMA is available per MAG. Specification of the End-To-End ATM Network Simulator Page: 10-96

182 6.2. Mobile Node's Policy Profile A mobile node's policy profile contains the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. These policy profiles are stored in a local or a remote policy store. Note: It is recommended that the MN policy profile is implemented as a global database that provides information to all interested parties (e.g. MAGs). All necessary information (MN-ID, home network prefix, home address, etc.) is stored within this database. The mobile access gateway and the local mobility anchor MUST be able to obtain a mobile node's policy profile. This specification requires that a mobile access gateway serving a mobile node MUST have access to its policy profile. The following are the mandatory fields of the policy profile: o The mobile node's identifier (MN-Identifier) The following are the optional fields of the policy profile: Note: The following already reduced list is considered as mandatory for the implementation. o The mobile node's IPv6 home network prefix(es) assigned to the mobile node's connected interface Acquiring Mobile Node's Identifier All the network entities in a Proxy Mobile IPv6 domain MUST be able to identify a mobile node, using its MN-Identifier. This identifier MUST be stable and unique across the Proxy Mobile IPv6 domain. Note: It is recommended that the MN-Identifier is globally unique. The mobility entities in the Proxy Mobile IPv6 domain MUST be able to use this identifier in the signalling messages and unambiguously identify a given mobile node. The following are some of the considerations related to this MN-Identifier. o The mobile access gateway MUST be able to identify the mobile node by its MN- Identifier. Specification of the End-To-End ATM Network Simulator Page: 10-97

183 Note: It is recommended to provide the MN-Identifier by means of a dedicated Logonexchange after the MN has attached to the access network. This should be performed on Layer 2 or at least prior to any other Neighbor Discovery or IP specific exchanges Home Network Emulation One of the key functions of a mobile access gateway is to emulate the mobile node's home network on the access link. It must ensure the mobile node does not detect any change with respect to its layer-3 attachment even after it changes its point of attachment in that Proxy Mobile IPv6 domain. For emulating the mobile node's home link on the access link, the mobile access gateway must be able to send Router Advertisement messages advertising the mobile node's home network prefix(es) carried using the Prefix Information option(s) [13] and with other address configuration parameters consistent with its home link properties. Typically, these configuration settings will be based on on a policy specific to each mobile node. Typically, the mobile access gateway learns the mobile node's home network prefix(es) details from the received Proxy Binding Acknowledgement message. However, the mobile access gateway SHOULD send the Router Advertisements advertising the mobile node's home network prefix(es) only after successfully completing the binding registration with the mobile node's local mobility anchor. Note: At least for foreign networks operating with PMIPv6, the MAGs will not advertise the home network prefix of the MN, but instead a care-of prefix that is stable across this very PMIPv6 domain. A mobile node will use this care-of prefix to configure it s care-of address that will be registered with the MNs Home Agent, following standard Mobile IPv6 behaviour [9] Signalling Considerations Binding Registrations Mobile Node Attachment and Initial Binding Registration 1. After detecting a new mobile node on its access link, the mobile access gateway MUST identify the mobile node and acquire its MN-Identifier. It MUST send a Proxy Binding Update message to the local mobility anchor. 2. The Proxy Binding Update message MUST include the Mobile Node Identifier option, carrying the MN-Identifier for identifying the mobile node. Note: Items 3-5 skipped. 6. The Timestamp option maintained on a per mobile node's mobility session basis MUST be present. The mobile access gateway SHOULD also set the Sequence Number field to a value of a monotonically increasing counter (maintained at each mobile access gateway and not to be confused with the per mobile node sequence number specified in [9]). The local mobility anchor will ignore this field when there is a Timestamp option Specification of the End-To-End ATM Network Simulator Page: 10-98

184 present in the request, but will return the same value in the Proxy Binding Acknowledgement message. This will be useful for matching the reply to the request message. 7. The Mobile Node Link-layer Identifier option carrying the link- layer identifier of the currently attached interface MUST be present in the Proxy Binding Update message, if the mobile access gateway is aware of the same. Note: Item 8 skipped. 9. The Link-local Address option MUST be present in the Proxy Binding Update message. Considerations from Section 6.8 MUST be applied. 10. The Proxy Binding Update message MUST be constructed as specified in Section If there is no existing Binding Update List entry for that mobile node, the mobile access gateway MUST create a Binding Update List entry for the mobile node upon sending the Proxy Binding Update message Receiving Proxy Binding Acknowledgement On receiving a Proxy Binding Acknowledgement message (format specified in Section 8.2) from the local mobility anchor, the mobile access gateway MUST process the message as specified below. Note: Items 1+2 skipped. 3. The mobile access gateway MUST apply the considerations specified in Section 5.5 for processing the Timestamp option in the message. Note: Items 4+5 skipped. 6. If the received Proxy Binding Acknowledgement message has any one or more of the following options, Mobile Node Link-layer Identifier option, Mobile Node Identifier option, carrying option values that are different from the option values present in the corresponding request (Proxy Binding Update) message, the message MUST be ignored as the local mobility anchor is expected to echo back all these listed options and with the same option values in the reply message. In this case, the mobile access gateway MUST NOT retransmit the Proxy Binding Update message until an administrative action is taken. Note: For the implementation it can be assumed that this will not happen. Note: Item 7 skipped. Specification of the End-To-End ATM Network Simulator Page: 10-99

185 8. If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp value lower than previously accepted value), the mobile access gateway SHOULD try to register again to reassert the mobile node's presence on its access link. The mobile access gateway is not specifically required to synchronize its clock upon receiving this error code. Note: Items 9-11 skipped. 12. If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor (if there is no existing bidirectional tunnel to that local mobility anchor). 13. The mobile access gateway MUST set up the route for forwarding the packets received from the mobile node using address(es) from its home network prefix(es) through the bi-directional setup for that mobile node. The created tunnel and the routing state MUST result in the forwarding behavior on the mobile access gateway as specified in Section The mobile access gateway MUST also update the Binding Update List entry to reflect the accepted binding registration values. It MUST also advertise the mobile node's home network prefix(es) as the hosted on-link prefixes, by including them in the Router Advertisement messages that it sends on that access link. Note: The RA should be unicasted directly to the MN, instead of using multicasting. The contained prefix is a care-of prefix instead of the home network prefix Mobile Node Detachment and Binding De-Registration If at any point the mobile access gateway detects that the mobile node has moved away from its access link, or if it decides to terminate the mobile node's mobility session, it SHOULD send a Proxy Binding Update message to the local mobility anchor with the lifetime value set to zero. This de-registration message MUST be constructed with the same set of options as the initial Proxy Binding Update message, under the considerations specified in Section However, the following exceptions apply. * There MUST be a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to the respective prefix value. Either upon receipt of a Proxy Binding Acknowledgement message from the local mobility anchor with the Status field set to 0 (Proxy Binding Update Accepted), or after INITIAL_BINDACK_TIMEOUT [9] timeout waiting for the reply, the mobile access gateway MUST do the following: 1. It MUST remove the Binding Update List entry for the mobile node from its Binding Update List. 2. It MUST remove the created routing state for tunneling the mobile node's traffic. Specification of the End-To-End ATM Network Simulator Page:

186 Constructing the Proxy Binding Update Message o The mobile access gateway, when sending the Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified below. IPv6 header (src=proxy-coa, dst=lmaa) Mobility header - BU /* P & A flags MUST be set to value 1 */ Mobility Options - Mobile Node Identifier option (mandatory) - Home Network Prefix option(s) (mandatory) - Timestamp option (optional) - Mobile Node Link-layer Identifier option (optional) - Link-local Address option (optional) Note: The Home Network Prefix Option will carry a care-of prefix. o The Source Address field in the IPv6 header of the message MUST be set to the global address configured on the egress interface of the mobile access gateway. This address will be considered as the Proxy-CoA for this Proxy Binding Update message. o The Destination Address field in the IPv6 header of the message MUST be set to the local mobility anchor address. o The Mobile Node Identifier option MUST be present. o At least one Home Network Prefix option MUST be present. o The Timestamp option MAY be present. o The Mobile Node Link-layer Identifier option MAY be present. o The Link-local Address option MAY be present Router Solicitation Messages A mobile node may send a Router Solicitation message on the access link shared with the mobile access gateway. The Router Solicitation message that the mobile node sends is as specified in [13]. The mobile access gateway, on receiving the Router Solicitation Specification of the End-To-End ATM Network Simulator Page:

187 message or before sending a Router Advertisement message, MUST apply the following considerations. 1. The mobile access gateway, on receiving the Router Solicitation message, SHOULD send a Router Advertisement message containing the mobile node's home network prefix(es) as the on-link prefix(es). However, before sending the Router Advertisement message containing the mobile node's home network prefix(es), it SHOULD complete the binding registration process with the mobile node's local mobility anchor. Note: It is recommended that the MAG ignores all Router Solicitations until the PBA was received. Upon reception of the PBA, the MAG automatically sends a Router Advertisement to the MN Default-Router In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-router for the mobile node on the access link. However, as the mobile node moves from one access link to another, the serving mobile access gateway on those respective links will send the Router Advertisement messages. If these Router Advertisements are sent using a different link-local address or a different link-layer address, the mobile node will always detect a new default-router after every handoff. For solving this problem, this specification requires all the mobile access gateways in the Proxy Mobile IPv6 domain to use the same link-local and link-layer address on any of the access links wherever the mobile node attaches. These addresses can be fixed addresses across the entire Proxy Mobile IPv6 domain, and all the mobile access gateways can use these globally fixed address on any of the point-to-point links Retransmissions and Rate Limiting The mobile access gateway is responsible for retransmissions and rate limiting the Proxy Binding Update messages that it sends to the local mobility anchor. The Retransmission and the Rate Limiting rules are as specified in [9]. However, the following considerations MUST be applied. 1. When the mobile access gateway sends a Proxy Binding Update message, it should use the constant, INITIAL_BINDACK_TIMEOUT [9], for configuring the retransmission timer, as specified in Section 11.8 [9]. However, the mobile access gateway is not required to use a longer retransmission interval of InitialBindackTimeoutFirstReg, as specified in [9], for the initial Proxy Binding Update message. 2. As specified in Section 11.8 of [9]., the mobile access gateway MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT [9]. 3. The retransmitted Proxy Binding Update messages MUST use the latest timestamp Forwarding Rules Forwarding Packets Sent to the Mobile Node's Home Network: o On receiving a packet from the bi-directional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST use the destination Specification of the End-To-End ATM Network Simulator Page:

188 address of the inner packet for forwarding it on the interface where the destination network prefix is hosted. The mobile access gateway MUST remove the outer header before forwarding the packet. If the mobile access gateway cannot find the connected interface for that destination address, it MUST silently drop the packet. Forwarding Packets Sent by the Mobile Node: o On receiving a packet from a mobile node connected to its access link, the mobile access gateway MUST ensure that there is an established binding for that mobile node with its local mobility anchor before forwarding the packet directly to the destination or before tunneling the packet to the mobile node's local mobility anchor. o On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bi-directional tunnel established between itself and the mobile node's local mobility anchor. However, the packets that are sent with the linklocal source address MUST NOT be forwarded. o The format of the tunneled packet is shown below. IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ Upper layer protocols /* Packet Content*/ Mobile Node Detachment Detection and Resource Cleanup The specific detection mechanism of the loss of a visiting mobile node on the connected link is specific to the access link between the mobile node and the mobile access gateway and is outside the scope of this document. In general, the mobile access gateway can depend on one or more of the following methods for the detection presence of the mobile node on the connected link: o Link-layer event specific to the access technology o Notification event from the local mobility anchor Note: If a MN moves to a new MAG of the same PMIPv6 domain and that MAG registers with the LMA, the LMA can send a notification to the old MAG that triggers the resource cleanup. 7. Mobile Node Operation This non-normative section explains the mobile node's operation in a Proxy Mobile IPv6 domain Moving into a Proxy Mobile IPv6 Domain When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on the access link detects the attachment of the mobile node and completes the binding registration with the mobile node's local mobility anchor. If the binding update operation is successfully performed, the mobile access Specification of the End-To-End ATM Network Simulator Page:

189 gateway will create the required state and set up the forwarding for the mobile node's data traffic. When a mobile node attaches to the access link, it will typically send a Router Solicitation message [13]. The mobile access gateway on the access link will respond to the Router Solicitation message with a Router Advertisement message. The Router Advertisement message will carry the mobile node's home network prefix(es), default-router address, and other address configuration parameters. If the mobile access gateway on the access link receives a Router Solicitation message from the mobile node, before it completes the signalling with the mobile node's local mobility anchor, the mobile access gateway may not know the mobile node's home network prefix(es) and may not be able to emulate the mobile node's home link on the access link. In such a scenario, the mobile node may notice a delay before it receives a Router Advertisement message. This will also affect mobile nodes that would be capable of handling their own mobility, or mobile nodes that do not need to maintain the same IP address through movements. If the received Router Advertisement message does not have the Managed Address Configuration flag set and if the mobile node is allowed to use autoconfigured address(es), the mobile node will be able to obtain IPv6 address(es) from each of its home network prefixes using any of the standard IPv6 address configuration mechanisms permitted for that mode. Once the address configuration is complete, the mobile node can continue to use this address configuration as long as it is attached to the network that is in the scope of that Proxy Mobile IPv6 domain Roaming in the Proxy Mobile IPv6 Domain After obtaining the address configuration in the Proxy Mobile IPv6 domain, as the mobile node moves and changes its point of attachment from one mobile access gateway to the other, it can still continue to use the same address configuration. As long as the attached access link is in the scope of that Proxy Mobile IPv6 domain, the mobile node will always detect the same router advertising itself as a default-router and advertising the mobile node's home network prefix(es) on each connected link. 8. Message Formats This section defines extensions to the Mobile IPv6 [9] protocol messages Proxy Binding Update Message Sequence # A H L K M R P Reserved Lifetime Specification of the End-To-End ATM Network Simulator Page:

190 . Mobility options A Binding Update message that is sent by a mobile access gateway to a local mobility anchor is referred to as the "Proxy Binding Update" message. A new flag (P) is included in the Binding Update message. The rest of the Binding Update message format remains the same as defined in [9]. Proxy Registration Flag (P) A new flag (P) is included in the Binding Update message to indicate to the local mobility anchor that the Binding Update message is a proxy registration. The flag MUST be set to the value of 1 for proxy registrations and MUST be set to 0 for direct registrations sent by a mobile node. Mobility Options As per this specification, the following mobility options are valid in a Proxy Binding Update message. These options can be present in the message in any order. There can be only one instance of the following options in the message: Mobile Node Identifier option Home Network Prefix option Timestamp option Mobile Node Link-layer Identifier option Link-local Address option 8.2. Proxy Binding Acknowledgement Message Status K R P Reserved Sequence # Lifetime Mobility options A Binding Acknowledgement message that is sent by a local mobility anchor to a mobile access gateway is referred to as the "Proxy Binding Acknowledgement" message. Specification of the End-To-End ATM Network Simulator Page:

191 A new flag (P) is included in the Binding Acknowledgement message. The rest of the Binding Acknowledgement message format remains the same as defined in [9]. Proxy Registration Flag (P) A new flag (P) is included in the Binding Acknowledgement message to indicate that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. The flag is set to a value of 1 only if the corresponding Proxy Binding Update had the Proxy Registration Flag (P) set to value of 1. Mobility Options As per this specification, the following mobility options are valid in a Proxy Binding Acknowledgement message. There cannot be more than one instance of any of the following options: Mobile Node Identifier option Home Network Prefix option Timestamp option Mobile Node Link-layer Identifier option Link-local Address option Status An 8-bit unsigned integer indicating the disposition of the Proxy Binding Update. Values of the Status field less than 128 indicate that the Proxy Binding Update was accepted by the local mobility anchor. Values greater than or equal to 128 indicate that the Proxy Binding Update message was rejected by the local mobility anchor. Section 8.9 defines the Status values that can used in Proxy Binding Acknowledgement message. For descriptions of other fields present in this message, refer to Section of [9] Home Network Prefix Option A new option, Home Network Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's home network prefix information. The format is as follows: Type Length Reserved Prefix Length Home Network Prefix + Specification of the End-To-End ATM Network Simulator Page:

192 Type 22 Reserved (R) This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Home Network Prefix A sixteen-byte field containing the mobile node's IPv6 Home Network Prefix Mobile Node Link-layer Identifier Option A new option, Mobile Node Link-layer Identifier option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's link-layer identifier. The format of the Link-layer Identifier option is shown below. Based on the size of the identifier, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [9] Type Length Reserved Link-layer Identifier Type 25 Reserved Specification of the End-To-End ATM Network Simulator Page:

193 This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Link-layer Identifier A variable length field containing the mobile node's link-layer identifier. The content and format of this field (including byte and bit ordering) is as specified in Section 4.6 of [13] for carrying link-layer addresses. On certain access links, where the link-layer address is not used or cannot be determined, this option cannot be used Link-local Address Option A new option, Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the link-local address of the mobile access gateway. The format is as follows: Type Length Link-local Address Type 26 Link-local Address A sixteen-byte field containing the link-local address Timestamp Option A new option, Timestamp option is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages. Specification of the End-To-End ATM Network Simulator Page:

194 The format is as follows: Type Length Timestamp Type 27 Timestamp A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second Status Values This document defines the following new Status values for use in Proxy Binding Acknowledgement messages. These values are to be allocated from the same number space, as defined in Section of [9]. Status values less than 128 indicate that the Proxy Binding Update message was accepted by the local mobility anchor. Status values greater than 128 indicate that the Proxy Binding Update was rejected by the local mobility anchor. TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 157 The timestamp value is lower than the previously accepted value Additionally, the following Status values defined in [9] can also be used in a Proxy Binding Acknowledgement message. 0 Proxy Binding Update accepted 9. Protocol Configuration Variables 9.1. Local Mobility Anchor - Configuration Variables The local mobility anchor MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts. Specification of the End-To-End ATM Network Simulator Page:

195 TimestampValidityWindow This variable specifies the maximum amount of time difference in milliseconds between the timestamp in the received Proxy Binding Update message and the current time of day on the local mobility anchor, that is allowed by the local mobility anchor for the received message to be considered valid. The default value for this variable is 300 milliseconds. This variable must be adjusted to suit the deployments Simplified Multihoming Protocol for Link Selection Algorithms In the frame of the simulation scenarios SIM_11 and SIM_12, the implementation of the full multihoming protocol (draft-ietf-monami6-mipv6-analysis-05) is abstracted and simplified in the following way: The mobile router (MR) as well as the Home Agent (HA) both keeps a list with all configured and registered IP addresses (1 IP address per link). As soon as a link is detected available, layer 2 connectivity is established automatically and the IP address is configured and registered. The HA and the MR add this new IP address then to their list of registered IP addresses. The signalling for the registration is abstracted here, i.e. no real datagrams are exchanged but the registration is done internally to the simulator. The information about the link status, i.e. delay, available throughput and SNR are signalled to the MR and the HA. The signalling via the IE_network primitive is hereby abstracted to providing the information simulation internally Simple Link Selection (without multihoming) Name: Conservative Link selection algorithm - Break Before Make (WP 3.1) Purpose: This algorithm is specified to be used with the SIM_01 scenario for break before make. The purpose of this algorithm is to select one link for data transmission if several links are present and could be used in case that the actual used link breaks. This algorithm is intended to work with a minimum amount of information, i.e. without Input values: Link up / link down status (Up=Link is available and can be used, Down=Link is not available and cannot be used) Actual flight phase (APT, TMA, ENR, ORP) User preference table (see below) Output values: Specification of the End-To-End ATM Network Simulator Page:

196 The link to be used for the communication Measurement values (maybe to be refined): As specified in the simulation report document Algorithm: For proper operation, a user preference table has to be setup, as shown in Table Domain Link Preference ENR Link4 3 Link8 2 Link6 1 ORP Link8 2 Link6 1 APT Link3 3 Link4 2 Table 10-1 User preference table For simulation scenario SIM_01, the first trigger for a link selection is the indication: Link is down The second trigger is a change of the flight domain, e.g. from APT to TMA. For simulation scenario SIM_02, the first trigger for a link selection is the indication: Link is going down The second trigger is a change of the flight domain, e.g. from APT to TMA. Among all links, the configured links form the set of alternatives A, unconfigured links in down-status are not elements of set A. From the set A, the first link alternative is selected for checking and denoted as x i in the following. Specification of the End-To-End ATM Network Simulator Page:

197 For x i it is then checked, whether the preference table P has an entry with the matching flight domain for link x i. If this is not the case, link x i is removed from A and the check is continued with link xi 1 This process is repeated for all elements of A. If all alternatives have been processed, it is checked whether the set A contains no alternatives, one alternative or several alternatives. If set A contains one alternative, this alternative is selected for transmission and the output of the algorithm. If set A contains more than one alternative, the one with the highest user preference value is selected for transmission and is the output of the algorithm If set A is empty, no link can be used. The algorithm is also illustrated in the following flowchart. Get attributes of alternative i Select Flight Domain Attribute NO x x 0 i,1 1 YES Discard alternative i i i max YES NO Choose remaining alternative YES Only one alternative remaining? NO Select link with highest preference Figure Flow chart of the simple link selection algorithm Specification of the End-To-End ATM Network Simulator Page:

198 In the flowchart, the flight phase at the time of the link down is denoted with 0 x Dynamic Link Selection (with multihoming) Name: Dynamic Link selection algorithm (WP 3.1) Purpose: The purpose of this algorithm is to select one link for data transmission if several links are present, registered and can be used. This algorithm is intended to work with a more sophisticated (compared to the simple link selection) set of link information as provided by IEEE Input values: information (IE_Network_QoS primitive) o Throughput R o Average/Maximum packet transfer delay o (Delay Jitter TBC Link up / link down status (Up=Link is available and can be used, Down=Link is not available and cannot be used) SNR Type of service, which shall be transmitted (ATC, AOC, AAC, APC) Actual flight phase (APT, TMA, ENR, ORP) User preference table (see below) Output values: The link to be used for the communication Algorithm: For proper operation, a user preference table has to be setup, as exemplary shown in Table Service Domain Link Preference ATS ENR Link4 3 Link8 2 Link6 1 ATS ORP Link8 1 AOC ORP Link6 1 Specification of the End-To-End ATM Network Simulator Page:

199 ATS APT Link3 3 Link4 2 Table 10-2 User preference table Whenever a transmission shall be done (i.e. for arriving data packets), the algorithm as shown in the flowchart in Figure is applied, whereas i_max denotes the maximum number of link alternatives at this time. The pre-screening phase in the first block of Figure is detailed in Figure Do prescreening for cut-off levels Choose remaining alternative YES Only one alternative remaining? NO Calculate SAW index for alternative i i i max YES NO Select link with highest SAW index Figure General flow of the dynamic link selection algorithm. Specification of the End-To-End ATM Network Simulator Page:

200 x x 0 i, j j x x 0 i, j j x x 0 i, j j j j max i i max Figure Pre-screening phase of the link selection algorithm. The purpose of the pre-screening phase is to remove any link alternatives which are connected but do not meet the required operational performance parameters. The prescreening works as follows: The set of all link alternatives is denoted as A. Links which are marked as DOWN are not elements of set A. For the pre-screening, the algorithm starts with the first link alternative i. For alternative i, the first attribute x i,1 is selected, i.e. the packet error rate P. The attribute x i,1 is then compared against the minimum required cut-off value If x i,1 > A. If x i,1 <= 0 x 1 (non-benefit attribute), then alternative i is discarded and removed from set 0 x 1, then the next attribute i,2 x (Delay) is checked. 0 x 1 Specification of the End-To-End ATM Network Simulator Page:

201 If the delay attribute x i,2 of alternative i is bigger than the required cut-off value x i,2 > (non-benefit attribute), then alternative i is discarded and removed from set A. Otherwise the next attributed, flight domain is checked. 0 x 2 If the flight domain attribute of alternative i ( x i,3 ) does not appear in the user preference table for the link alternative i (category attribute) xi,3 P i, then the alternative i is removed from set A, otherwise it remains in A and the service type attribute x i,4 is checked. If the service type attribute x i,4 of alternative i does not appear in the user preference table for link i, then alternative i is removed from the set A, otherwise it remains in A. At this point, only the link alternatives i remain in the set A, which meet the operational requirements (cut-off values) and are configured by the user for this situation. If only one link alternative i remains, then this alternative is directly selected for transmission. Otherwise, a simple additive weighting among the link attributes is done as follows: The simple additive weighting sum is calculated according to the following formula: A w x i j i, j A i is the SAW index value of alternative i. i, j w j is the normalized weight for attribute j. x is the normalized link attribute value and The normalization of the link attribute values is done in the following way: For non-benefit attributes (Delay, Delay Jitter, Packet Error Rate), the following calculation method is applied: max k k, j max x i, j max k xk, j xi, j k xk, j min xk, j x hereby denotes the maximum occurring attribute value for attribute j, among all link alternatives k. min k x k, j alternatives k. denotes the minimum occurring attribute value for attribute j, among all link k Specification of the End-To-End ATM Network Simulator Page:

202 As an example take the following delay attribute values: Link A: 10ms A Link B: 250ms B Link C: 120ms C,, xk, j min xk, j max xk j xi j max k i k k 250ms i max max min 250ms 10ms k k k k k k 1 A B C For benefit attributes (Throughput, Time before loss, User Preference) the normalization is done in this way: xi, j x i, j max x As an example, take the following (arbitrary) numbers for the time before link loss: TA TB TC 15s 120 s 360s k A k, j 15s T A s 120 s T B s 360 s T C s The weights for the different attributes are a simulation parameter which would be good to iterate to improve results. Specification of the End-To-End ATM Network Simulator Page:

203 After the SAW index values have been computed for all different link alternatives with the formulas presented above, the link with the highest SAW index is chosen for transmission. In case no link meets the requirements of the pre-screening phase, the SAW value shall be re-calculated for all link options, including the ones who originally were discarded during the pre-screening. Specification of the End-To-End ATM Network Simulator Page:

204 11 Appendix C Implementation of COCR Data Traffic Model This section describes in a first place the flight parameters used as "trigger events" for the generation of the ATS, AOC and NET data traffic and give examples for the NEWSKY simulation scenarios as shown in the later tables of the sections 11.5 to It supplements the service descriptions given in the following Appendices D, E and F. Each of these service descriptions addresses the two elements: Condition and Description for message exchange. The general content of these two elements is further elaborated right hereafter. The specific details for each service message are listed then in the corresponding Appendices D, E, and F Conditions for message exchange Each service description provides two tables within this section referring to one of the two timeframes (i.e. the COCR phases) marking the transition from voice-based services to data-based services. Note that the conditions for message exchanges differ in phase 1 and phase 2. Message exchanges are characterized by the following properties: Message triggers (labeled Message exchange at ) Number of exchanges Probability of exchange Aircraft type (only in phase 2) Each of these properties is described in detail below Message Triggers The triggering of a message is related to the current position of the aircraft. In order to specify an aircraft's position as accurately as possible, three parameters are considered: Domain Phase Position Domain The domain of an aircraft can be APT, TMA, ENR, ORP or AOA. These abbreviations correspond to the airspace domains defined in [4] and cited in Table 11-1 below. Specification of the End-To-End ATM Network Simulator Page: 11-1

205 Table 11-1: COCR domain definitions. Domain Description Vertical Dimensions Horizontal Dimensions APT TMA ENR ORP AOA Airport surface and immediate vicinity of the airport Transition airspace used by Air Traffic Control (ATC) to merge and space aircraft for landing or for entering the Enroute domain. In [4] it is assumed that the given definition of the domain is valid for arrival as well as for departures. Airspace that surrounds the TMA domain, continental or domestic airspace used by ATC for the cruise portion of the flight. It also includes areas to the lower limits of controlled airspace (e.g feet) where airport or TMA does not exist. The Oceanic, Remote, Polar domain is the same as the ENR domain, except that it is associated with geographical areas generally outside of domestic airspace. A defined block of airspace which is associated with autonomous operations where aircraft selfseparate (i.e. Air Traffic Control is not used). The defined block may change vertical or horizontal limits or usage times based on, among other factors, traffic densities. up to ~5000 ft ~5000ft up to ~FL245 ~FL245 to ~FL600 ~10 miles in diameter around the airport ~50 nautical miles from the center of an airport 300 nautical miles to 500 nautical miles not specified 1000 nautical miles 2000 nautical miles not specified 400 nautical miles 800 nautical miles The definition of the horizontal extent of the ORP domain is rather generic. Consequently it is not well suited for the present estimation of data traffic that is based on empiric data and thus relies heavily on the accurate definition of boundaries. In order to meet the required precision, a more specific definition of the ORP domain than the one given in [4] report is necessary. See Note that the AOA domain is only used for Phase 2 scenarios. Some data services are triggered in the AOA domain. However, similar to the ENR domain, the given description for AOA is rather generic. In order to achieve the required degree of accuracy in the simulations a clear-cut definition is necessary. Therefore the following assumptions are taken: Both, ENR and ORP domain vertically extend to FL 450. Any airspace above FL 450 is considered AOA Specification of the End-To-End ATM Network Simulator Page: 11-2

206 An illustration of the discussed flight domains is given in Figure Figure 11-1: Flight domains as used in the data traffic simulation Phase The Phase of the Flight can be Departure, Cruise, or Arrival Position The Position attribute can be Ground, Tower, Ramp, Takeoff, Climb, Landing, or Domain. Tower, Ramp, Takeoff, and Landing are used in [4] to differentiate the status of an aircraft being at or arriving/departing an airport. Climb is used to indicate that the aircraft is climbing to its cruise flight level in the ENR domain. The Domain value indicates that the service in question is triggered whenever the domain (e.g. ENR) is entered. Some services are triggered per ATC sector (Sector) or by the current Air Traffic Control Unit (ATSU) Number of exchanges The trigger events define the conditions to start a complete message exchange. This attribute indicates the number of packet exchanges to be carried out in this exchange sequence Probability of exchange The purpose of this attribute is to indicate the probability of the exchange to take place. Specification of the End-To-End ATM Network Simulator Page: 11-3

207 Aircraft type Referring to [4], the communications capabilities of the aircraft equipment are indicated by this attribute. Type I aircraft are equipped with basic data link equipment, whereas Type II aircraft are fully COTRAC equipped. The equipment rate is taken from the figures given in [4], according to which 20 % of the aircraft in Phase II will have basic equipage mounted. The remaining 80 % of aircraft will support advanced data communications due to being equipped with COTRAC capable equipment. The first category of aircraft is referred to as Type I, whereas the latter group of aircraft is classified as Type II Description of message exchange Whereas the previous section gives an exhaustive description of the conditions under which message exchanges are triggered this section is concerned with the exact proceedings how these message exchanges take place. The following aspects are used to characterize the communications effort for each service: Type of service Forward Link Reverse Link Message Sizes and Quantities Class of Service - Performance Requirements Type of Service This category indicates whether the service is addressed to one specified receiver or it is a broadcast service. The NEWSKY simulations contain only services with type of service addressed Forward Link and Reverse Link The FL and RL information of each service description of the Appendices D, E, and F provide textural descriptions the content of the messages that are sent via each of the two links. Note that there may be several types of messages depending on the purpose of the service Message Sizes and Quantities For each service the quantitative characteristics of a message are listed in a table. There is one table for both, Type I and Type II aircraft. However, message exchanges for a service may differ from Phase 1 to Phase 2. Additionally, sizes and numbers of messages on the Forward Link are not necessarily equal to those on the Reverse Link. Specification of the End-To-End ATM Network Simulator Page: 11-4

208 Class of Service - Performance Requirements Within the NEWSKY simulations the performance requirements are only used to determine the class of service of a data link application (i.e. data link service). Within each service description the corresponding tables provide performance related information on each service. This information is summarized from [4], chapter 5: Performance Requirements. However, the figures in these tables do not influence the simulations in any way and serve only as additional characterizations of the services. For each performance parameter differentiations are taken per domain (APT, TMA, ENR, ORP and AOA) and per Phase (Phase 1 and Phase 2). The performance parameters are Expiration Time and Latency: Expiration time RCTP Latency RCTP Expiration time FRS Latency FRS Class of Service The expiration time refers to the maximum tolerable waiting time for a transmission before it is considered to have failed. The latency value denotes the expected one-way transmission time of a packet including all processing and queuing delays. Application Presentation Session Transport Net Inter Sub Data Link Physical DS Upper Layer Fast Byte (P) Fast Byte (S) TP4 or CLTP CLNP/IDRP/ESIS Mobile SNDCF Data Link Physical Application E.g. TELNET FTP, etc TCP (Transport) IP (Internet) IEEE 802, X.25 ARPANET 1822 (Network) TP4 or CLTP ATS/AOC Applications (CM, CPDLC, ADS, FIS) FRS Boundary Figure 11-2: FRS Boundary Point Examples As illustrated in Figure 11-2, the FRS requirements refer to the virtual boundary that divides the Network Layer of the ISO/OSI Reference Model into an inter-net and sub-net layer. Thus, the values Expiration time FRS and Latency FRS do only consider peer-topeer data traffic from the sender's FRS boundary to the receiver's boundary. RCTP values on the other hand refer to end-to-end communications from the sender's application to the receiver's application. The Class of Service parameter reflects the FRS latency requirements of [4]. It is explicitly noted that these classes are not inseparably connected to the services but rather act as optional parameters. Classes of services indicate the priority assigned to each service. They range from DG-A through DG-L with decreasing priority. Specification of the End-To-End ATM Network Simulator Page: 11-5

209 Note: The COCR service classes are connected to the FRS latency requirements. However for the NEWSKY end-to-end performance the end-to-end latency requirement (called RCTP requirement) is relevant. Note: Table 11-2 is sorted in alphabetical order and not according to priority. Class of Service (CoS) Table 11-2: COCR classes of service. Required Expiration Time (ET) (s) Required 95% percentile (TD95-FRS) (s) DG-A NET DG-B DG-C DG-D DG-E DG-F DG-G DG-H DG-I DG-J DG-K DG-L Service Type ATS AOC 11.3 Assumptions As the specifications of the data services given in [4] do not provide the degree of accuracy required in the context of the NEWSKY evaluation, several assumptions had to be taken in order to adequately implement the simulations. These assumptions are discussed in this section Air Traffic Sectors and Domains For a range of services changes between different TMA/ENR ATC sectors are important. Sector and domain changes were modelled by the NAVSIM 4 air traffic simulation tool according to recorded EUROCONTROL CMFU data (i.e. radar data) and flight plans ORP Domain In the COCR study, the Oceanic, Remote and Polar domain (ORP) is defined as follows: "The ORP domain is the same as the ENR domain, except that it is associated with 4 The Air Traffic/ ATC and CNS Simulation Tool NAVSIM has been developed by Mobile Communications Research and Development ForschungsGmbH in close co-operation with University of Salzburg. Specification of the End-To-End ATM Network Simulator Page: 11-6

210 geographical areas generally outside of domestic airspace." 5 Therefore the ORP airspace has been determined according to this definition and based on the Digital Aeronautical Information File (DAFIF) of the US National Geospatial Intelligence Agency (NGA). Within this document the air-space structure of 2007 has been taken into account. An illustration of the area in question is given in Figure The ORP region is coloured blue. Figure 11-3: ORP region (blue) according to COCR and DAFIF Air Traffic Service Units Some messages exchanges are triggered by an ATSU change. Each country is assumed to have exactly one Air Traffic Service Unit (ATSU). Every time an aircraft enters airspace belonging to a different country, the ATSU responsible for the aircraft is assumed to change. Note that we do not use the coastline as border, but the border of the airspace belonging to each country according to the Digital Aeronautical Information File (DAFIF) of the US National Geospatial Intelligence Agency (NGA) Triggering of message exchanges The number and size of messages corresponding to each service is specified in [4] as well as the probability of the message exchange taking place. However, it is not specified at which point of the flight these message exchanges are affected. For this reason this document defines for each service if a message exchange takes place at the beginning or at the end of a flight phase. If no appropriate description is given in [4], exchange will start at a random point in time. 5 [4] p. 20 Specification of the End-To-End ATM Network Simulator Page: 11-7