NEMO Basic Support Protocol NEMO Design Team Vijay Devarapalli - - PowerPoint PPT Presentation

IETF 57th NEMO WG

NEMO Basic Support Protocol

NEMO Design Team Vijay Devarapalli (NOKIA) Ryuji Wakikawa (Keio/WIDE) Alexandru Petrescu (Motorola) Pascal Thubert (Cisco Systems)

IETF 57th NEMO WG

NEMO Basic Support draft is out

• Design Team was formed after the IETF SF
• Initial draft

– draft-ietf-nemo-basic-support-00.txt

• Issue list

– http://people.nokia.net/vijayd/nemo/issues.html

• Comments should be posted to

– nemo ML (nemo@ietf.org)

IETF 57th NEMO WG

NEMO Basic Support Protocol

MR

Internet Internet

HA CN MNN B i

• d

i r e c t i

• n

a l T u n n e l MNP – MR HoA

Binding Cache

MR HoA – MR CoA

IP-in-IP Encapsulation

IETF 57th NEMO WG

Explicit and Implicit Signaling

MR

Internet Internet

HA

Binding Cache

MR HoA – MR CoA

MNP – MR HoA

• 1. Binding Update
• 2. Binding Acknowledgement

IP header HoA BU (R) MNP/len

Explicit Binding Update

IP header HoA BU (R)

Implicit Binding Update

Prefix Table

MR HoA - MNP

IP header HoA BU (R) Pfx-len IPsec IPsec IPsec Mobile Network Prefix Option Mobile Network Prefix Length Option

IETF 57th NEMO WG

• 6 issues raised (4 accepted, 1 open, 1 rejected)

– http://people.nokia.net/vijayd/nemo/issues.html

• Issue 6

– How does HA distinguish between implicit mode and dynamic routing protocol – An explicit flag in the binding update

• Resolution

– No Flag, because it is a matter of configuration on the Home Agent – Do we need to check consistency of prefixes between routing protocol and BU signaling

• Issue 3

– Should HA forward packets for the MNNs to the MR if the ‘R’ flag was set to 0

• Resolution

– No. If R flag was set to 0, the MR wants to to be considered as a mobile host. HA MUST NOT forward

– Should HA store prefix information in the binding cache entry

• Resolution

– Yes. In explicit case, useful for deleting the prefix routes when the binding cache entry is deleted

Issues Status

IETF 57th NEMO WG

Extended Home Network (issue 5)

HA

Home Network a:b:c:1::/64 MNP2 a:b:c:2::/64 MNP3 a:b:c:3::/64 MNP4 a:b:c:4::/64

Extended Home Network a:b:c::/48 MR2 MR3 MR4 Classical Home Address MRn HoA a:b:c:1::EUI64 MNP a:b:c:n::/64 Extended Home Address MRn HoA a:b:c:n::Xi MNP a:b:c:n::/64

IETF 57th NEMO WG

Returning extended home network

HA MR

Ingress IF Egress IF

MR MR proxy a:b:c::/48 a:b:c:n:/64

Ingress IF Egress IF

HA a:b:c::/48 Proxy Model Rocket Model

IETF 57th NEMO WG

For example, it is expected that:

• There is a single Home Network and multiple Mobile

Networks

• The Home Network and Mobile Network prefixes are

tailored to allow for IPv6 Stateless Address Autoconfiguration with typical interface identifier length for the type of interface

• The prefix length of the extended Home Network is

shorter than the Home Network and the Mobile Network prefixes, since it is an aggregation

• The Home Agents collectively advertise the extended

Home Network aggregation only. The dichotomy of the extended Home Network is kept within the Home Agents and the Mobile Nodes, as opposed to advertised by means of routing protocols to other parties

IETF 57th NEMO WG

This specification does not prevent that

• More than one Mobile Network may be

connected to a Mobile Router

• A Mobile Network Prefix may be shared

between Mobile Routers and registered by some of them

• An Mobile Network Prefix may be registered

several times to several Home Agents using different (extended) Home Addresses for each registration

IETF 57th NEMO WG

This draft is open to

• Mobile Router autoconfiguring one or several

extended Home Address to carry out many registrations in parallel. It owns the full prefix so it may use any address in there for a MNLP based registration, and several of them for multihoming

• Mobile Node autoconfiguring one or several Care-
• f Addresses from the Mobile Network Prefix
• Mobile Host autoconfiguring one or several Home

Addresses from the Home Network

IETF 57th NEMO WG

Fin.

A N Y Q U E ST IO N S O R C O M M E N T S?