1 / 13

NEMO Multi-homing Issues

NEMO Multi-homing Issues. Prepared for 56 th IETF NEMO WG By Ng Chan Wah & Takeshi Tanaka 19 03 2003. Deployment Scenarios (1/4). Multiple Egress Interfaces, Single HA. HA. Internet. MR. 802.11 Interface CoA=2::1, HoA=1::1. GPRS Interface CoA=3::1, HoA=1::2. Prefix=1:1::/96.

amos
Télécharger la présentation

NEMO Multi-homing Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NEMO Multi-homing Issues Prepared for 56th IETF NEMO WG By Ng Chan Wah & Takeshi Tanaka 19 03 2003 56th IETF – NEMO Working Group

  2. Deployment Scenarios (1/4) • Multiple Egress Interfaces, Single HA HA Internet MR 802.11 Interface CoA=2::1, HoA=1::1 GPRS Interface CoA=3::1, HoA=1::2 Prefix=1:1::/96 MNN-1 MNN-2 Addr=1:1::1 Addr=1:1::2 56th IETF – NEMO Working Group

  3. Deployment Scenarios (2/4) • Multiple Egress Interfaces, Different HAs HA-2 HA-1 Internet MR 802.11 Interface CoA=3::1, HoA=1::1 GPRS Interface CoA=4::1, HoA=2::1 Prefix=1:1::/96, 2:1::/96 Addr=1:1::2 Or 2:1::2 Addr=1:1::1 Or 2:1::1 MNN-1 MNN-2 56th IETF – NEMO Working Group

  4. Deployment Scenarios (3/4) • Multiple MRs, Single HA HA Internet CoA=3::1 HoA=1::2 CoA=2::1 HoA=1::1 MR-2 MR-1 Prefix=1:1::/96 Prefix=1:1::/96 MNN-1 MNN-2 Addr=1:1::2 Addr=1:1::1 56th IETF – NEMO Working Group

  5. Deployment Scenarios (4/4) • Multiple MRs, Different HAs HA-2 HA-1 Internet CoA=4::1 HoA=2::1 CoA=3::1 HoA=1::1 MR-2 MR-1 Prefix=2:1::/96 Prefix=1:1::/96 Addr=1:1::2 Or 2:1::2 Addr=1:1::1 Or 2:1::1 MNN-1 MNN-2 56th IETF – NEMO Working Group

  6. Issues • When MR detects a failed egress link, how can NEMO recover? • As per IPv6: • Nothing much • send ICMP dest unreachable • wait for possible recovery by dynamic routing protocol • But this is undesired for NEMO with multiple egress links • Should NEMO try to incorporate mechanism that allows faster recovery? • Considering that we expect link failures to occur far more frequently in NEMO 56th IETF – NEMO Working Group

  7. HA-2 HA-1 Internet MR-2 MR-1 RA(LifeTime!=0) MNN-2 MNN-1 Possible Approach (1/2) • MR dynamically change its tunnel entry interface when its egress link fails • MR need to detect the presence of other MRs having alternate routes in its local network • possibility: listen for RA with LifeTime!=0 56th IETF – NEMO Working Group

  8. HA-2 HA-1 Internet Obtain CoA MR-2 MR-1 Re-establish tunnel MNN-2 MNN-1 Possible Approach (2/2) • Obtain CoA from other MRs when its egress link fails • Re-establish bi-directional tunnel using this new CoA X • Issues: • Possible looping when both MRs’ egress link fails 56th IETF – NEMO Working Group

  9. Mailing List - Resolved • Requirements Draft • issue raised on multiple addresses configure to single interface (mentioned in the terminology draft) • similar issues when home link is multi-homed • consensus: • Non-NEMO specific • Should not be worked on 56th IETF – NEMO Working Group

  10. Mailing List - Unresolved • Requirements R13 • R12: The solution MUST function for multi-homed mobile networks. • R13.1: The solution MUST support mobile networks with multiple MRs. In particular, if the path through one MR becomes unavailable, the solution MUST be able to establish new communications between MNNs and CNs using an alternative available path through another MR. Additionally, if the path through one MR becomes unavailable, the solution SHOULD (or MAY?) preserve established communications by re-routing the packets of such communication through an alternative available MR. • R13.2: The solution MUST support MR with multiple interfaces. In particular, if the path through one of the MR interfaces becomes unavailable, the solution MUST be able to establish new communications between MNNs and CNs using an alternative available interface of the MR. Additionally, if the path through one MR interfaces becomes unavailable, the solution MUST (or SHOULD?) preserve established communications by coursing packets of such communication through an alternative available interface of the MR 56th IETF – NEMO Working Group

  11. Mailing List - Unresolved • Requirements R13 • Change to • NEMO solution SHOULD not prevent the use of any form of multi-homing 56th IETF – NEMO Working Group

  12. Mailing List - Unresolved • Issue of multiple MR, different HA, advertising same prefixes • requires co-ordination between HA • Issue of multiple MR, different HA, advertising different prefixes • does not matter which prefix LMN choose to use, it can send packet to any MR as next hop router • however, also requires co-ordination between HA • Is NEMO WG working on a solution for such cases? 56th IETF – NEMO Working Group

  13. Mailing List – Unresolved • Issue on MR with multiple egress interface, single HA • argument that we cannot have a single HoA assigned to both egress interface and active at the same time, since a single HoA cannot be bound to two (or more) CoAs simultaneously • possibility of multiple CoAs bound to same HoA • Draft-wakikawa-mipv6-multiplecoa-00.txt 56th IETF – NEMO Working Group

More Related