[PPT] - Network Mobility Thierry Ernst Keio University PowerPoint Presentation

SLIDE 1

Thierry Ernst - Nautilus6.org - September 2004

1

Network Mobility

Thierry Ernst

Keio University ernst@sfc.wide.ad.jp

SLIDE 2

Thierry Ernst - Nautilus6.org - September 2004

2 IP-layer Mobility: Host Mobility and Network Mobility

MN AR MN

Prefix1::id_MN Prefix1::id_MR

HA

Prefix1.1::id_MR Prefix1.1::id_MR

BR

Prefix1

Prefix2::id_MR

AR

Prefix2

Prefix2::id_MN Prefix1.1::id_MR

Address Requirements for IPv6 nodes:

Must be topologically correct Each interface must have an address formed after the prefix advertised on the link where it is attached

IP-layer Mobility

Change of point of attachment = change of IP subnet Change of IP subnet = change of the routing directive

MN MN

Prefix1::id_MN Prefix1::id_MR Prefix1.1::id_MR Prefix1.1::id_MR

BR

Prefix1

Prefix2::id_MR

AR

Prefix2

Prefix2::id_MN Prefix1.1::id_MR

SLIDE 3

Thierry Ernst - Nautilus6.org - September 2004

3

AR

MR-HoA: P1::id_MR

HA

NEMO-Prefix::id_MR NEMO-Prefix::id_MR

BR

HomeLink: P1/48

✗

IETF NEMO Basic Support: draft-ietf-nemo-basic- support

✗

Goal: Session Maintenance

✗

Initialisation

✗

NEMO-prefix identifes all nodes in the mobile network

✗

MR_HoA: MR's egress interface on home link

Movement to Foreign Link

✗

MR retains HoA

✗

MR obtains CoA on its visited link

✗

CoA is bound to NEMO-prefix, not HoA

✗

MNNs retain their initial addresses

IP-layer Mobility: Network Mobility Support

MNNs AR

ForeignLink: P2/64

NEMO-Prefix::id_MR MR-CoA: P2::id_MR MR-HoA: P1::id_MR NEMO-Prefix::id_MR NEMO-Prefix::id_MR

BR

HomeLink: P1/48

MNNs AR

ForeignLink: P2/64

NEMO-Prefix::id_MR MR-CoA: P2::id_MR

SLIDE 4

Thierry Ernst - Nautilus6.org - September 2004

4 IETF NEMO Basic Support: draft-ietf-nemo-basic-support

AR Internet HA MR

Prefix 1/60 ->Prefix2::/128 (MRCoA)

NEMO-Prefix P1/60 Prefix P2/64 Prefix P1/48 NEMO-Prefix P1/60

MR

Assumption:

All MNNs have an address on NEMO-Prefix CoA bound to NEMO-Prefix

Registration

Registration with HA:

NEMO-prefix-> MR' CoA

instead of

MR's HoA-> MR's CoA

HA records a network-specific route instead of host-specific Bidirectional tunnel between MR and HA

NEMO-Prefix S:MR D:HA

SLIDE 5

Thierry Ernst - Nautilus6.org - September 2004

5 IETF NEMO Basic Support: draft-ietf-nemo-basic-support

MR AR Internet HA

Prefix 1/60 ->MR CoA

S:CN D:LFN S:CN D:LFN S:HA D:MR-CoA S:CN D:LFN NEMO-Prefix P1/60 P2/64 P1/48

Routing

Encapsulation between HA and MR in BOTH directions Not optimal solution, but guarantee mobile networks are supported with minimal effort

SLIDE 6

Thierry Ernst - Nautilus6.org - September 2004

6 Benefit of network mobility support over host mobility support

Network Mobility Support (NEMO Basic Support)

The vehicle changes its point of attachment to the Internet

Host Mobility: each node maintains Internet access

Each host must perform Mobile IPv6

Network Mobility: only the mobile router (MR) maintains Internet access

Standards IPv6 nodes can be located behind the MR: no mobility support

Host Mobility Support (Mobile IPv6)

SLIDE 7

Thierry Ernst - Nautilus6.org - September 2004

7 NEMO vs MANET

P_Renault_1::id_MR MR_CoA:P_Road::id_MR

HA_Renault HomeLink: P_RenaulRoad/64

A NEMO can be made of MANET nodes

MNNs in the NEMO can be MANET nodes e.g.: the train (NEMO) and the passengers (MANET nodes)

A MANET can be made of NEMOs

MANET nodes are MRs each with a network behind e.g.: a car is a MANET router, with an embedded NEMO behind the MR

AR Road-side ForeignLink: P_Road/64

SLIDE 8

Thierry Ernst - Nautilus6.org - September 2004

8

NEMO Issues

SLIDE 9

Thierry Ernst - Nautilus6.org - September 2004

9

MR2 LFN

NEMO Basic Support Issue: Nested Mobility

HA2 CN Internet AR HA1 MR1

Cost of multiple encapsulation

Packet size ; Packet Fragmentation (PMTU) Latency Processing overhead at MR, HA Extremely sub-optimal routing (Pin Ball routing)

Sol investigated in:

draft-ng-nemo-access-router-option-00.txt draft-thubert-nemo-reverse-routing-header- 01.txt Others

MR2 LFN

SLIDE 10

Thierry Ernst - Nautilus6.org - September 2004

10

Internet AR MR

Requirement R12 draft-ietf-nemo-requirements-02.txt NEMO Basic Support must allow the mobile network

To connect to the Internet via several access networks To switch to the best available technology

Multihoming

A mobile network connected to the Internet via several interfaces

1 Mobile Router with heterogeneous access medias More than 1 Mobile Router

Cases:

Multiple MRs Multiple HAs Multiple NEMO-prefixes

Result:

Multiple CoAs Multiple HoAs

AR

Multiple interfaces Multiple MRs

MR AR

NEMO Basic Support & Multihoming

SLIDE 11

Thierry Ernst - Nautilus6.org - September 2004

11 NEMO Basic Support & Multihoming: draft-ietf-nemo-multihoming-issues Benefits of multihoming:

Ubiquitous access, Redundancy Flexibility, via distinct physical medium or access networks Load Sharing. Load Balacing Bi-casting

Problem: Multihoming introduces new issues:

Multiple NEMO-Prefixes: Source address selection Multiple MR: MR selection / redirection to other MR Nested and multihoming Issues are not NEMO-specific, but it's more important to solve those issues in the NEMO context because mobile networks are more likely to be multihomed than fixed networks.Taxonomy

Taxonomy:

X: Number of Mobile Routers (#MRs) Y: Number of Home Agents (#HA) Z: Number of NEMO-Prefixes advertised in the mobile network

Total: 8 cases

Not all are useful

SLIDE 12

Thierry Ernst - Nautilus6.org - September 2004

12

HA-1 HA-1 MR-2 MR-2 MNN-1 MNN-1 MNN-2 MNN-2 HA-2 HA-2 MR-1 MR-1

Internet Internet

Tunnel re-establisment:

MR dynamically change its tunnel entry interface when its egress link fails

Obtain CoA from other MRs when egress link fails Re-establish bi-directional tunnel using this new CoA

Issue:

MR need to detect the presence of other MRs having alternate routes in its local network: Possibility: listen for RA with LifeTime!=0 Possible routing loop when both MRs' egress link fail

RA(LifeTime!=0) RA(LifeTime!=0)

NEMO Basic Support & Multihoming: Issues

HA-1 HA-1 MR-2 MR-2 MNN-1 MNN-1 MNN-2 MNN-2 HA-2 HA-2 MR-1 MR-1

Internet Internet

X X

Obtain Obtain CoA CoA Re-establish tunnel Re-establish tunnel

SLIDE 13

Thierry Ernst - Nautilus6.org - September 2004

13 MR has Multiple Egress Interfaces, 1 CoA associated with each

✗

e.g.: laptop

Goal: To maintain bidirectional tunnel over each inferface

HA HA MR MR MNN-1 MNN-1

GPRS Interface GPRS Interface CoA=3::1, HoA=1::2 CoA=3::1, HoA=1::2 802.11 Interface 802.11 Interface CoA=2::1, HoA=1::1 CoA=2::1, HoA=1::1 Addr=1:1::1 Addr=1:1::1 Prefix=1:1::/96 Prefix=1:1::/96

MNN-2 MNN-2

Addr=1:1::2 Addr=1:1::2

3::1 3::1 1::2 1::2 2::1 2::1 1::1 1::1 CoA CoA HoA HoA Binding Cache Binding Cache 1::1 1::1 1:1::/96 1:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table

Internet Internet NEMO Basic Support & Multihomed: Case (1MR,1Ha,1P)

SLIDE 14

Thierry Ernst - Nautilus6.org - September 2004

14 For Redundancy: Efficient link failure detection mechanism For Load-Sharing: Ability to register several CoAs for a prefix and to exchange priority level for each CoA For Policy-routing: Exchange preference with MR and HAMR has Multiple Egress Interfaces, 1 CoA associated with each

HA HA MR MR MNN-1 MNN-1

GPRS Interface GPRS Interface CoA=3::1, HoA=1::2 CoA=3::1, HoA=1::2 802.11 Interface 802.11 Interface CoA=2::1, HoA=1::1 CoA=2::1, HoA=1::1 Addr=1:1::1 Addr=1:1::1 Prefix=1:1::/96 Prefix=1:1::/96

MNN-2 MNN-2

Addr=1:1::2 Addr=1:1::2

3::1 3::1 1::2 1::2 2::1 2::1 1::1 1::1 CoA CoA HoA HoA Binding Cache Binding Cache 1::1 1::1 1:1::/96 1:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table

Internet Internet NEMO Basic Support & Multihomed: Case (1MR,1Ha,1P)

SLIDE 15

Thierry Ernst - Nautilus6.org - September 2004

15 Multiple Egress Interfaces, Different HAs

e.g.: distinct serive providers

Bi-directional tunnels must be established between each (MR,HAy)

HA-1 HA-1 MR MR

GPRS Interface GPRS Interface CoA=4::1, HoA=2::1 CoA=4::1, HoA=2::1 802.11 Interface 802.11 Interface CoA=3::1, HoA=1::1 CoA=3::1, HoA=1::1 Prefix=1:1::/96, 2:1::/96 Prefix=1:1::/96, 2:1::/96

3::1 3::1 1::1 1::1 CoA CoA HoA HoA Binding Cache Binding Cache 1::1 1::1 1:1::/96 1:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table 4::1 4::1 2::1 2::1 CoA CoA HoA HoA Binding Cache Binding Cache 2::1 2::1 2:1::/96 2:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table

HA-2 HA-2 MNN-1 MNN-1

Addr=1:1::1 Addr=1:1::1 Or 2:1::1 Or 2:1::1

MNN-2 MNN-2

Addr=1:1::2 Addr=1:1::2 Or 2:1::2 Or 2:1::2

Internet Internet NEMO Basic Support & Multihomed: Case (1MR,nHA,1P)

SLIDE 16

Thierry Ernst - Nautilus6.org - September 2004

16 Multiple MRs, Single HA

e.g.: PAN

Bi-directional tunnels must be established between each (Mrx,HA) MR must be selected by MNNs

Just use router selection mechanisms

HA HA MR-2 MR-2 MNN-1 MNN-1

CoA=3::1 CoA=3::1 HoA=1::2 HoA=1::2 Addr=1:1::1 Addr=1:1::1 Prefix=1:1::/96 Prefix=1:1::/96

MNN-2 MNN-2

Addr=1:1::2 Addr=1:1::2

MR-1 MR-1

CoA=2::1 CoA=2::1 HoA=1::1 HoA=1::1 Prefix=1:1::/96 Prefix=1:1::/96

Internet Internet

3::1 3::1 1::2 1::2 2::1 2::1 1::1 1::1 CoA CoA HoA HoA Binding Cache Binding Cache ??? ??? 1:1::/96 1:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table

NEMO Basic Support & Multihomed: Case (nMR,1HA,1P)

SLIDE 17

Thierry Ernst - Nautilus6.org - September 2004

17 Multiple MRs, Different HAs

e.g.: in-vehicle network

MNNs with multiple addresses perform source address selection

HA-1 HA-1 MR-2 MR-2 MNN-1 MNN-1

CoA=4::1 CoA=4::1 HoA=2::1 HoA=2::1 Addr=1:1::1 Addr=1:1::1 Or 2:1::1 Or 2:1::1 Prefix=2:1::/96 Prefix=2:1::/96

MNN-2 MNN-2

Addr=1:1::2 Addr=1:1::2 Or 2:1::2 Or 2:1::2

3::1 3::1 1::1 1::1 CoA CoA HoA HoA Binding Cache Binding Cache 1::1 1::1 1:1::/96 1:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table 4::1 4::1 2::1 2::1 CoA CoA HoA HoA Binding Cache Binding Cache 2::1 2::1 2:1::/96 2:1::/96 Next Hop Next Hop Dest Dest Routing Table Routing Table

HA-2 HA-2 MR-1 MR-1

CoA=3::1 CoA=3::1 HoA=1::1 HoA=1::1 Prefix=1:1::/96 Prefix=1:1::/96

Internet Internet NEMO Basic Support & Multihomed: Case (nMR,nHA,nP)

SLIDE 18

Thierry Ernst - Nautilus6.org - September 2004

18 NEMO Basic Support & Multihomed: Summary Case (1MR,1HA,1P)

Bi-directional tunnels established over each inferface

Case (nMR,1HA,1P):

Bi-directional tunnels established between each (MRx,HA) MR must be selected by MNNs

Just use router selection mechanisms

Case (1MR,nHA,1P):

Bi-directional tunnels must be established between each (MR,HAy)

Case (1MR,1HA,nP):

Distinct prefixes:

MNNs with multiple addresses must perform source address selection

Other issues are the same as in case (1,1,1)

Cases (n,1,n) ; (1,n,n) ; (n,n,n):

Bi-directional tunnels established between EACH pair (MRx,HAy)

Cases translate into (n,1,1) ; (1,n,1) ; (n,n,1)

Disruption of service when a tunnel fails due to:

Ingress filtering (administrative reason) Another address is used (thanks to source address selection)

SLIDE 19

Thierry Ernst - Nautilus6.org - September 2004

19

NEMO Issue: Routing Optimization

SLIDE 20

Thierry Ernst - Nautilus6.org - September 2004

20 Mobility Problem # types

Access Networks in public transportation Networks of sensors in vehicles Personal Area Networks

# usages

Transportation / Health-care / Army /

# configurations

Single mobile IP-subnet

MNN may be fixed (LFNs), or mobile (VMNs, LMNs)

Multiple mobile IP-subnet

May be a static configuration: in a vehicle May be mobile on from another: multiple cars forming a train May be nested: hierarchy of NEMO

Multihomed

Multiple interfaces, multiple MRs

Nested and Multihomed

SLIDE 21

Thierry Ernst - Nautilus6.org - September 2004

21 Mobility Problem # mobility patterns

Local-mobility: e.g. Trains vs Global-mobility: e.g. Private cars High mobility frequency vs Moving seldomly Predictive vs non Predictive MANET of NEMO vs NEMO of MANET

All of these types, usages, configurations, mobility patterns imply different cases where RO is needed:

RO between a MNN and CN in the infrastructure RO between MNNs in distinct NEMOs RO between MNNs within the same NEMO For each of the above,

The NEMO is possibly nested MNNs and CNs may be fixed or mobile In case of multihoming, there may be multiple routes

Potentially complex problem to solve

SLIDE 22

Thierry Ernst - Nautilus6.org - September 2004

22 Approaches Potential Categories of Approaches

Two-tier addressing :

Mobile IPv6-like, HMIPv6, Correspondent Router

Separation between identifier and locator: e.g. LIN6 Multicast Overlay Network: e.g. ORC Routing-Based: using conventional or ad-hoc routing protocols Renumbering: changing address/prefix Combined

e.g.1 Routing for local mobility (within the AS) and Two-tier for global mobility (between ASs)

A specific approach may be more suitable for the type of RO

e.g.: Ad-hoc routing protocols in nested NEMO solely made of individual mobile IP-subnet Elected solution will probably be a combination of some of the above

SLIDE 23

Thierry Ernst - Nautilus6.org - September 2004

23 RO a la MIP6: Taxonomy Many personal propositions have been submitted They usually do not address the same issues, or all of them The WG needs a problem statement document draft-thubert-nemo-ro-taxonomy is a potential candidate

Taxonomy of RO models in NEMO

The Route Optimization problem space can be split into 4 possible types [Thubert02]:

RO between MR and the CN RO from visiting mobile host RO with the routing infrastructure RO for nested mobile network + RO within the mobile network

Tradeoffs:

Which entity to modify (MR, CN, MNN, intermediate router)

SLIDE 24

Thierry Ernst - Nautilus6.org - September 2004

24

VMN Internet AR HA_MR MR CN Internet AR HA_MR MR CN

RO a la MIP6: Routing Optimization Issues

HA_MN MN LFN MR VMN2 VMN1 Internet AR HA_MR HA_MN1 HA_MN2 VMN1 VMN2

From CN to Local Fixed Node From CN to Visiting Mobile Node Between 2 Visiting Mobile Nodes

MR2 LFN Internet AR HA_MR1 MR1 CN HA_MR2 MR2 LFN

From CN to LFN in nested NEMO

SLIDE 25

Thierry Ernst - Nautilus6.org - September 2004

25 MR performs RO on behalf of MNNs Pros:

HA is bypassed Transparent to MNNs

No mobility support needed, can be plain IPv6 hosts

MR, CN, HA are the only entities involved

Cons:

BU explosion:

not scalable for large number of CNs

MIPv6 RR (Reverse Routability) test between MR and CN is broken

because MNNs not reachable AT MR's CoA, but VIA MR's CoA

Changed needed at the CN

RO a la MIP6: RO between MR/VMN and CN

Internet AR MR HA CN AR MNN

SLIDE 26

Thierry Ernst - Nautilus6.org - September 2004

26 VMN / LMN participates in NEMO RO Pros:

HA is bypassed for VMNs / LMNs May further reduce the number of tunnels required

Cons:

No RO for LFNs Impact the operations of VMH, MR, and HA

RO a la MIP6: RO from Visiting Mobile Node

VMN / LMN Internet AR MR HA CN AR LFN

SLIDE 27

Thierry Ernst - Nautilus6.org - September 2004

27 Routing is optimized between CR (Correspondent Router) and MR/VMN

Add routes in specific routers

Pros

CN can be a plain IPv6 host i.e. No mobility support function at all

Cons:

May impact the operations of VMN, MR and HA

Refs:

ORC [Wakikawa], CR [Thubert]

RO a la MIP6: RO with routing infrastructure

VMN Internet AR MR HA CN CR MMN

SLIDE 28

Thierry Ernst - Nautilus6.org - September 2004

28 RO a la MIP6: RO for nested mobile network Root-MR maintains a tunnel to each HA Pros:

Reduce the number of tunnels Should impact only operations of MR and HA

Cons

Packets still experience ‘dog-leg’ routing

Internet HA_VMR AR root_MR VMR VMN root_HA HA_VMN CN AR LFN

SLIDE 29

Thierry Ernst - Nautilus6.org - September 2004

29

Nautilus Activities

SLIDE 30

Thierry Ernst - Nautilus6.org - September 2004

30 Introduction: The IPv6 All-Mobile Internet: Scenario

Wired or Wireless LAN

(WaveLAN, HiperLAN,..)

Autoconfiguration Horizontal handoff (Mobile IPv6) NEMO, Multihoming, Nested, Security, AdHoc, QoS Vertical handoff (HMIPv6?) AAA Multicast Mobile IPv6, AAA Seamless mobility, QoS, RO

SLIDE 31

Thierry Ernst - Nautilus6.org - September 2004

31 The IPv6 All-Mobile Internet: Sunrise of IPv6 Deployment

Seamless mobility IPv6 Quality of Service Route Optimization

Required for performance Required for mobility

Network Mobility Support Host Mobility Support Global Mobility

Required for deployment

Security Access Control and Accounting Auto-configuration IPv4 to IPv6 transition mechanisms Operational Management

Required to convince

Applications

SLIDE 32

Thierry Ernst - Nautilus6.org - September 2004

32 The IPv6 All-Mobile Internet: Required Features & Protocols

For Mobility:

Host Mobility: Mobile IPv6 (only needs implementation brush up) Network Mobility: NEMO Ubiquitous Mobility: Vertical & horizontal handoffs / multihoming / nested mobility

For Deployment

Access Control and Accounting (AAA) Security: IPSec, key mngt mechanisms, certificates IPv4 to IPv6 transition mechanisms (IPv4 traversal) Autoconfiguration Operational mngt (services dispatching, evaluation, scalability, ...) Mobility-related and non-mobility-related Applications

For Performance

IPv6 (scalability, evolutivity) Seamless mobility (FMIPv6, L2 triggers) Quality of Service Routing Optimization Adhoc routing ? Multicast ?

SLIDE 33

Thierry Ernst - Nautilus6.org - September 2004

33 Phase-1: Operational Testbed - Zaurus Goal: Demonstrate Mobile IPv6's Operationality Testbed:

Access Networks: 802.11, Ethernet 2 HA: K2 (Shin-Kawasaki, Japan) & ULP Strasbourg, France) PDAs: 40 Zaurus SL-C760 running Linux 2.4.18 provided to WIDE members

Mobile IPv6 (horizontal handoffs) Mobility-friendly applications: VoIP [Linphone], Streamer Video receiver [MPlayer], WebBrowser [Konquer]

Transition mechanisms: L2TP

1st step: fall 03–fall 04: PDAs provided to WIDE members

Conclusions: not used, because lack of IPv6 connectivity and attractive IPv6 applications

2nd step: fall 04-: PDAs provided to SOI students

Video streaming Evaluation: Collect data, conduct performance analysis

SLIDE 34

Thierry Ernst - Nautilus6.org - September 2004

34 Phase-1: Demonstration Testbed Goal:

Demonstrate the combination of host-mobility, network mobility & multihoming

How:

Design generic testbed that can be used for distinct usages Usages: E-Walker / E-Back / E-Bike /E-Wheechair i.e. as you like

What

Nested mobile network Live video streaming and monitoring Permanent access using distinct access mediums

Interface switching (horizontal & vertical handoffs) Flow(s) is adapted to bandwidth.

Testbed:

Access Networks: 802.11, AirH, Ethernet 1st PAN of equipement on a vehicle (wheelchair, bicycle)

MR + IPv6 camera / IPv6 GPS / PDA / navigation tool connected to MR

2nd PAN of sensors on the body

PDA, IPv6 Heart-beat sensor / IPv6 temperature sensor

SLIDE 35

Thierry Ernst - Nautilus6.org - September 2004

35 Phase-1: Demonstration Testbed - Scenario Scenario

On-the-Move and live video-conferencing / video streaming and monitoring PAN is moving around (street, city, house, office, campus) Person is moving out of the Wheelchair / Bicycle

E-Wheelchair

Monitoring for the disabled and the elderly remote monitoring between wheelchair and third party (hospitals, doctor, family)

E-Bicycle

Monitoring of the performance / health condition of the cyclist Easy to carry to conferences, attractive demonstration

IPv6 Sen sor Mobile Routeur PDA Webcam PAN

SLIDE 36

Thierry Ernst - Nautilus6.org - September 2004

36 E-Wheelchair: PAN (Personal Area Network) on the Wheelchair IPv6 Sensor Mobile Routeur PAN PDA Webcam

SLIDE 37

Thierry Ernst - Nautilus6.org - September 2004

37 E-Wheelchair: PAN on the body attached to PAN on Wheelchair IPv6 Sen sor Mobile Routeur PDA Webcam PAN Heart-beat Sensor

Wireless Lan Public Internet Access Public Internet Access

On-Body PAN

SLIDE 38

Thierry Ernst - Nautilus6.org - September 2004

38

Wireless Lan

Internet Phase-1: Demonstration Testbed - Equipment

Mobile Router

Sony VAIO Type U70 Provides permanent Internet access to the other equipements Multiple egress interfaces: 802.11, PHS (AirH, or B-Mobile, i.e. ako GPRS in Japan) Interface switching (vertical and horizontal handoffs)

PDA

Web access, emails, etc Can be taken away from the PAN

Webcam IPv6

Streaming video Adapted to available bandwidth

SLIDE 39

Thierry Ernst - Nautilus6.org - September 2004

39 IPv6 Sensor BOX HUB(modified) Mobile Router Power

IPv6 sensors designed by WIDE

Temperature + Humidity / 2-axis Acceleration / Direction / GPS

Embedded on the Wheelchair Monitoring

Have an IPv6 stack (i.e. And Ipv6 address) and a MIB

Queried using SNMPv1/UDP/IPv6 Information displayed with MRTG

Powered from Power over Ethernet (PoE) switch Need reloadable battery with more than 2 hours autonomy

IPv6 Heartbeat sensor under development Phase-1: Demonstration Testbed - Equipment

SLIDE 40

Thierry Ernst - Nautilus6.org - September 2004

40 NEMO

Validation of NEMO BS Implementation *BSD Implementation of NEMO BS on Linux (2.6 / MIPL 2.0) Evaluation of NEMO BS Test of NEMO RO solutions (nested NEMOs) Prefix Delegation

Multihoming

Problem Statement Test of Multihoming in fixed networks Test of Multihoming under NEMO BS Multiple MRs, switching between MRs Interface switching mechanisms Adaptive Application

Seamless Mobility

Implementation of FMIPv6

Misc

Test of AAA mechanisms (1 implementation from INT) Multicast: MLD

Phase-1: Indoor Testbed (Spring 03 – Fall 04)

SLIDE 41

Thierry Ernst - Nautilus6.org - September 2004