MEXT Working Group                                          C. Bernardos
Internet-Draft                                               M. Calderon
Intended status: Experimental                                    I. Soto
Expires: January 8, 2009                                            UC3M
                                                            July 7, 2008


     Correspondent Router based Route Optimisation for NEMO (CRON)
                   draft-bernardos-mext-nemo-ro-cr-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 8, 2009.

Abstract

   The Network Mobility Basic Support protocol enables networks to roam
   and attach to different access networks without disrupting the
   ongoing sessions that nodes of the network may have.  By extending
   the Mobile IPv6 support to Mobile Routers, nodes of the network are
   not required to support any kind of mobility, since packets must go
   through the Mobile Router-Home Agent (MRHA) bi-directional tunnel.
   Communications from/to a mobile network have to traverse the Home
   Agent, and therefore better paths may be available.  Additionally,
   this solution adds packet overhead, due to the encapsulation.

   This document describes an approach to the Route Optimisation for



Bernardos, et al.        Expires January 8, 2009                [Page 1]


Internet-Draft            CR-based RO for NEMO                 July 2008


   NEMO, based on the well-known concept of Correspondent Router.  The
   solution aims at meeting the currently identified NEMO Route
   Optimisation requirements for Operational Use in Aeronautics and
   Space Exploration.  Based on the ideas that have been proposed in the
   past, as well as some other extensions, this document describes a
   Correspondent Router based solution, trying to identify the most
   important open issues.

   The main goal of this first version of the document is to describe an
   initial NEMO RO solution based on the deployment of Correspondent
   Routers and trigger the discussion within the MEXT WG about this kind
   of solution.

   This document (in an appendix) also analyses how a Correspondent
   Router based solution fits each of the currently identified NEMO
   Route Optimisation requirements for Operational Use in Aeronautics
   and Space Exploration.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].




























Bernardos, et al.        Expires January 8, 2009                [Page 2]


Internet-Draft            CR-based RO for NEMO                 July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Correspondent Router Prefix Option . . . . . . . . . . . .  7
   4.  Mobile Router operation  . . . . . . . . . . . . . . . . . . .  8
     4.1.  Conceptual Data Structures . . . . . . . . . . . . . . . .  8
     4.2.  Correspondent Router Discovery . . . . . . . . . . . . . .  9
     4.3.  Correspondent Router Binding . . . . . . . . . . . . . . . 10
   5.  Correspondent Router operation . . . . . . . . . . . . . . . . 12
     5.1.  Conceptual Data Structures . . . . . . . . . . . . . . . . 12
     5.2.  Correspondent Router Binding . . . . . . . . . . . . . . . 13
     5.3.  Intercepting Packets from a Correspondent Node . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Analysis of CRON and the Aeronautics requirements . . 16
     A.1.  Req1 - Separability  . . . . . . . . . . . . . . . . . . . 16
     A.2.  Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 17
     A.3.  Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 17
     A.4.  Req4 - Availability  . . . . . . . . . . . . . . . . . . . 18
     A.5.  Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 18
     A.6.  Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 19
     A.7.  Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 19
     A.8.  Req8 - Security  . . . . . . . . . . . . . . . . . . . . . 20
     A.9.  Req9 - Adaptability  . . . . . . . . . . . . . . . . . . . 20
     A.10. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 20
     A.11. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 21
     A.12. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 21
     A.13. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 21
     A.14. Des5 - Generality  . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23














Bernardos, et al.        Expires January 8, 2009                [Page 3]


Internet-Draft            CR-based RO for NEMO                 July 2008


1.  Introduction

   This document assumes that the reader is familiar with the
   terminology related to Network Mobility [5] and [6] (Figure 1), and
   with the Mobile IPv6 [2] and NEMO Basic Support [3] protocols.

   The goals of the Network Mobility (NEMO) Support are described in
   [7].  Basically, the main goal is to enable networks to move while
   preserving the communications of their nodes (Mobile Network Nodes,
   or MNNs), without requiring any mobility support on them.  The NEMO
   Basic Support protocol [3] consists on setting a bi-directional
   tunnel (Figure 2) between the Mobile Router (MR) of the network (that
   connects the mobile network to the Internet) and its Home Agent
   (located at the Home Network of the mobile network).  This is
   basically the Bi-directional Tunnel (BT) operation of Mobile IPv6
   (MIPv6) [2], but without supporting Route Optimisation.  Actually,
   the protocol extends the existing MIPv6 Binding Update (BU) message
   to inform the Home Agent (HA) of the current location of the mobile
   network (i.e. the MR's Care-of Address, CoA), through which the HA
   has to forward the packets addressed to the network prefix managed by
   the MR (Mobile Network Prefix, or MNP).

                         ---------
                         | HA_MR |
                         ---------
                             |
       ------    +-----------+---------+
       | CN |----|      Internet       |
       ------    +---+-----------------+
                      |
                    ------       ------------------------------
                    | AR |       | AR: Access Router          |
                    ------       | CN: Correspondent Node     |
                       |         | MR: Mobile Router          |
             ===?==========      | HA_MR: MR's Home Agent     |
                MR               | MNP: Mobile Network Prefix |
                |                | MNN: Mobile Network Node   |
         ===|========|====(MNP)  ------------------------------
            MNN     MNN

               Figure 1: Basic scenario of Network Mobility

   Because of the bi-directional tunnel that is established between HA
   and MR to transparently enable the movement of networks, the NEMO
   Basic Support protocol introduces the following limitations:
   o  It forces suboptimal routing (known as angular or triangular
      routing), since packets are always forwarded through the HA
      following a suboptimal path and therefore adding a delay in the



Bernardos, et al.        Expires January 8, 2009                [Page 4]


Internet-Draft            CR-based RO for NEMO                 July 2008


      packet delivery.
   o  It introduces non-negligible packet overhead, reducing the Path
      MTU (PMTU).  An additional IPv6 header (40 bytes) is added to
      every packet because of the MRHA bi-directional tunnel.
   o  The HA becomes a bottleneck of the communication.  This is
      because, even if a direct path is available between a MNN and a
      CN, the NEMO Basic Support protocol forces traffic to follow the
      CN-HA=MR-MNN path.  This may cause the Home Link to be congested,
      resulting in some packets discarded.

   In order to overcome such limitations, it is necessary to provide
   what have been called Route Optimisation for NEMO [8], [9], [10],
   [11].

    __            _____                              __             ___
   |  |          |     |                            |  |           |   |
   |CN|          |HA_MR|                            |MR|           |MNN|
   |__|          |_____|                            |__|           |___|
    |               |                                 |               |
    | ------------  | ------------------------------  | ------------  |
    | |S:CN,D:MNN|  | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]|  | |S:CN,D:MNN|  |
    | |   DATA   |  | |            DATA            |  | |   DATA   |  |
    | ------------  | ------------------------------  | ------------  |
    |-------------->|-------------------------------->|-------------->|
    |               |                                 |               |
    |  ------------ |  ------------------------------ |  ------------ |
    |  |S:MNN,D:CN| |  |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| |  |S:MNN,D:CN| |
    |  |   DATA   | |  |            DATA            | |  |   DATA   | |
    |  ------------ |  ------------------------------ |  ------------ |
    |<--------------|<--------------------------------|<--------------|
    |               |                                 |               |

                   Figure 2: NEMO Basic Support protocol

   This document collects some ideas about a Route Optimisation scheme
   based on optimising the routing path between an MNN and a CN by
   setting up a bi-directional tunnel between the MR of the NEMO and a
   router topologically close to the CN, called Correspondent Router
   (CR).  Packets of the communication between the MNN and the CN could
   then use this bi-directional tunnel instead of the default MRHA one,
   in this way optimising the resulting routing path.

   While this idea is far from being new ([12], [9]), the re-chartering
   of the MEXT WG (formerly NEMO WG) to specifically address and work on
   the design of a solution targeting a set of particular use case
   scenarios (namely aeronautics [13], vehicular [14] and consumer
   electronics [15]) makes worthwhile revisiting the idea of a CR-based
   NEMO RO solution and analyse whether this kind of approach would fit



Bernardos, et al.        Expires January 8, 2009                [Page 5]


Internet-Draft            CR-based RO for NEMO                 July 2008


   the requirements of those scenarios.  This document is a first
   attempt of doing so, focused on the requirements for Operational Use
   in Aeronautics and Space Exploration.


2.  Protocol Overview

   The approach described in this document, called Correspondent Router
   based Route Optimisation for NEMO (CRON), is based on the idea of
   extending the NEMO Basic Support protocol [3] to enable the MR
   managing bindings not only with the HA, but also with special
   routers, called Correspondent Routers (CRs), so the MRHA tunnel can
   be bypassed for traffic addressed to CNs that are topologically close
   to a CR.

   CRON basically works as follows: an MR is forwarding packets to
   several communications between MNNs of the NEMO and CNs located in
   the Internet.  For some of these communications, the MR may decide
   that it is better to try to avoid the use of the MRHA tunnel and try
   to set up a binding with a CR close to the other end-point of the
   communication (i.e. the CN).  In order to do so, the MR needs to know
   whether there are any potential CRs that can be used and their IPv6
   addresses.  Once the MR knows that, it can select a CR among the
   potential ones (if any) and decide to establish a binding with it.
   To do so, a Binding Update/Binding Acknowledgement message exchange
   takes place.  Once the signalling has occurred, the MR sets up a bi-
   directional tunnel with the CR and adds a routing entry towards the
   IPv6 prefix/address managed by the CR (the CN prefix), using the CR
   as next hop (through the established tunnel).  Analogously, the CR
   sets up a routing entry towards the MNP/MNN IPv6 address, using the
   MR's CoA as next hop through the established tunnel.  At this point,
   the traffic between the MNN (or set of MNNs with IPv6 addresses from
   a particular MNP) and the CN (or set of CNs with IPv6 addresses from
   a particular CN prefix) no longer traverses the HA, since the bi-
   directional tunnel established between the MR and the CR is used
   instead.

   Next sections of this document describe in more detail the operation
   of CRON.  It is not the goal of this first version to provide a
   complete and exhaustive specification (many details are not
   included), but rather to list the key operations that would be
   required for such a CR-based solution work, and, more importantly,
   identify the key requirements/assumptions/open issues that remain to
   be solved.  This last point would be potentially very dependant on
   the considered NEMO RO use case.






Bernardos, et al.        Expires January 8, 2009                [Page 6]


Internet-Draft            CR-based RO for NEMO                 July 2008


3.  Message Formats

3.1.  Correspondent Router Prefix Option

   The Correspondent Router Prefix Option is included in the Binding
   Updates to indicate to the Correspondent Router the CN prefix (could
   also be a host address) that is requested to be route optimised.
   This information and the prefix included in the Mobile Network Prefix
   Option ([3]) is used by the CR to know which packets have to be sent
   through the MR-CR bi-directional tunnel.  There could be multiple
   Correspondent Router Prefix Options if the CR is able to route
   optimise traffic from different CN prefixes and the MR wants traffic
   from more than one of these prefixes to be optimised.  This option is
   also included by the CR in the BA messages.

   The Correspondent Router Prefix Option has an alignment requirement
   of 8n+4.  Its format is as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |   Length      |   Reserved    | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                  Correspondent Router Prefix                  +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:
      Number to be assigned by IANA.

   Length:
      Eight-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.  Set to 18.

   Reserved:
      This field is unused for now.  The value MUST be initialized to 0
      by the sender and MUST be ignored by the receiver.

   Prefix Length:
      Eight-bit unsigned integer indicating the prefix length of the
      IPv6 prefix contained in the option.

   Correspondent Router Prefix:



Bernardos, et al.        Expires January 8, 2009                [Page 7]


Internet-Draft            CR-based RO for NEMO                 July 2008


      A sixteen-byte field containing the Correspondent Router Prefix.


4.  Mobile Router operation

   The Mobile Router operation defined by the NEMO Basic Support
   protocol [3] is extended in order to be able to set up bindings with
   different CRs and establish bi-directional tunnels with them, used to
   route part of the traffic as indicated by the MR's policies.

   The process of NEMO RO set-up MUST be initiated by the MR, and cannot
   be initiated by the CR.  Next sections elaborate more on the
   different operations and mechanisms required to complete the whole
   NEMO RO.

4.1.  Conceptual Data Structures

   In addition to the data structures defined in [3], the MR needs also
   to maintain the following information:

   o  The MR extends the Binding Update List (BUL) to contain also some
      information per each communication that is being route optimised.
      Basically the added fields are the following:
      *  A flag specifying whether the entry is a Correspondent Router
         entry or not.
      *  Source IPv6 optimised prefix: this field contains the IPv6
         address/prefix of those MNNs whose traffic is being optimised
         by using an MR-CR bi-directional tunnel with the CR.  There
         could be multiple instances of this field in the BUL of the MR.
         These are basically the IPv6 addresses/prefixes included in the
         Mobile Network Prefix options carried in the BU/BA signalling
         exchanged by the MR and the CR.
      *  Destination IPv6 optimised prefix: this field contains the IPv6
         address/prefix of those CNs whose traffic is being optimised by
         using an MR-CR bi-directional tunnel with the CR.  There could
         be multiple instances of this field in the BUL of the MR.
         These are basically the IPv6 addresses/prefixes included in the
         Correspondent Router Prefix options carried in the BU/BA
         signalling exchanged by the MR and the CR.
   o  The MR SHOULD have a policy database that contains information
      regarding which communications should be route optimised and which
      not.  It is up to the implementation the decision about the exact
      content of this database, as well as if it can be dynamically
      updated or it is pre-configured statically.







Bernardos, et al.        Expires January 8, 2009                [Page 8]


Internet-Draft            CR-based RO for NEMO                 July 2008


4.2.  Correspondent Router Discovery

   Prior to the binding establishment and tunnel set-up between an MR
   and a CR, the MR MUST find out whether there exist a CR that can be
   used to optimise the route between an attached MNN (or set of MNNs,
   having IPv6 addresses from the same MNP) and a CN (or set of CNs,
   having IPv6 addresses from the same IPv6 prefix).  Besides, if there
   exist such a CR, the MR needs to know some information about it, such
   CR's IPv6 address.

   This information may be known beforehand by the MR, by means of a
   static pre-configuration of the list of usable CRs and some
   additionally required information.  Although it is up to the
   implementers to decide how this static information has to be
   processed and handled, the CR information MAY be indexed in a manner
   similar to a routing table, so when an MR has a target IPv6 address/
   prefix to which it wants to search for a candidate CR, it can perform
   a look-up in the CR database and get the most suitable CR (that is,
   the CR that is topologically closest to the target, using the
   longest-match prefix rule).

   Although a static configuration might be enough for several
   scenarios, it seems desirable to support dynamic CR discovery.  This
   is one of the hardest problems that a CR-based solution poses.  There
   have been different proposals to tackle this problem.  We next
   present the fundamentals of some of those, as well as some new ones:

   o  If the CR is assumed to be always on the path between the MR to
      the CN (e.g., the CR is the gateway of the CN), the CR could
      inspect all received packets looking for a particular message.  In
      this way, when there is a communication that is a candidate for
      being route optimised, the MR can send a BU message to the CN.  If
      there is a CR available, the first CR on the path towards the CN
      would capture that packet (not forwarding it to the next hop) and
      process it accordingly.  This approach seems to have severe
      limitations, since it assumes that available CRs will always be on
      the MR-CN path, but it deserves to be listed as it might be the
      case that this assumption is reasonable for some of the use cases
      currently considered by the MEXT WG.
   o  Discovery based on/assisted by the DNS.  The DNS service might be
      used in different ways, such as adding new type of registers, or
      including an 'A' register for the CR of each particular domain.
      In the latter case, the solution would work as follows: an MR
      attempting to optimise a certain MNN-CN communication would
      perform a reverse DNS query -- using the IPv6 address of the CN --
      to obtain the qualified DNS name of the CN.  Using the obtained
      name, the MR would perform a query of the name 'CR.domainname',
      where 'domainname' is the domain part of the previously obtained



Bernardos, et al.        Expires January 8, 2009                [Page 9]


Internet-Draft            CR-based RO for NEMO                 July 2008


      name.  The 'A' register of 'CR.domainname' would contain (if that
      CR exists) the IPv6 address(es) of the CR(s) of that domain.  This
      solution has also some drawbacks, since it assumes that each
      potential CN has a domain name published in the DNS, and assumes
      that all nodes belonging to a topological domain share the same
      domain names.
   o  Use of a CR anycast address.  The ORC draft [12] proposes the
      definition of anycast addresses for the CRs.  In this way, the MR
      learns the CR anycast address from the CN's prefix and the defined
      anycast suffix.  Using this anycast address, the MR sends CR
      discovery requests, waiting for CR discovery replies, in a way
      similar to the DHAAD mechanism of Mobile IPv6 [2].  This mechanism
      shares the limitations of DHAAD.
   o  Deployment of CR-resolver servers.  Given that some of the
      currently addressed use cases involve kind-of controlled
      environments, where certain trust relationships might be safely
      assumed, the deployment of a (potentially distributed, even in a
      hierarchical way) CR-resolver service may be considered.  These
      CR-resolver servers would keep the a repository of CR-related
      information, including the IPv6 address of the CRs managing a
      particular IPv6 prefix/address.  Every CR should keep that
      repository updated, so MRs can send queries to look for candidate
      CRs (the CR-resolver service would return the best CR, that is the
      one serving the longest-match prefix).  In order to ensure the
      integrity of the stored information, CRs MUST have some type of
      security relationship with the CR-resolver service, so only
      authorised CRs can modify the stored information.  Analogously,
      MRs SHOULD also have some trust relationship, so the MR is
      provided with some security guarantees regarding the authenticity
      of the information retrieved from CR-resolvers.  It is also worth
      evaluating if it would be better that the HA is the one querying
      the CR-resolvers, and that the obtained information is provided to
      the MR through the HA (it might reduce the bandwidth consumption
      on the MR wireless access links and also reduce the number of
      required trust relationships).  Both the requirement of deploying
      this CR-resolver service and the assumption of the existence of
      trust relationships should be carefully analysed for each of the
      currently addressed NEMO RO scenarios, in order to evaluate
      whether they are reasonable or not.  This CR discovery approach
      needs further work, TBD after gathering WG feedback about it.

4.3.  Correspondent Router Binding

   Once the MR has learnt the IPv6 address of a CR that can be used to
   route optimise some traffic, it needs to perform the Binding
   Registration to this CR.  The MR sends a Binding Update message
   protected with IPsec/IKE.  It is assumed that MRs would have
   certificates that contain information regarding the Mobile Network



Bernardos, et al.        Expires January 8, 2009               [Page 10]


Internet-Draft            CR-based RO for NEMO                 July 2008


   Prefixes they are authorised to manage and their Home Address.  It is
   also assumed that CRs would trust on those certificates, for example
   by means of a shared PKI infrastructure.  Again, it needs to be
   discussed whether this assumption is too strong or it is reasonable
   for a given NEMO RO scenario (it seems that for AOS domain this
   requirement is less strong than for ATS domains [16]).

   The Binding Update sent by the MR to the CR MUST have the Mobile
   Router (R) Flag set to 1, indicating to the CR that the BU is from an
   MR.  The Home Registration (H) Flag MUST be set to 0.  In this way, a
   CR that also implements the Home Agent functionality can
   differentiate Home Registration Binding requests from Correspondent
   Router Binding requests.

   All BUs sent by MRs to CRs requesting a Correspondent Router Binding
   MUST carry at least a Mobile Network Prefix Option, containing the
   IPv6 prefix/address of the MNN(s) whose traffic is requested to be
   optimised.  Therefore, only explicit binding mode is supported.

   All BUs sent by MRs to CRs requesting a Correspondent Router Binding
   MUST carry at least a Correspondent Router Prefix Option, containing
   the IPv6 prefix/address of the CN(s) whose traffic is requested to be
   optimised.  Traffic generated by nodes whose IPv6 addresses are not
   from the prefixes contained in these option, with destination the
   MNPs contained in the Mobile Network Prefix Option, MUST NOT be route
   optimised (the normal route MUST be used instead).

   An MR MUST generate a different BU message per each MNN-CN (or MNP-CN
   Prefix) pair that wants to be optimised.  Note that a binding is not
   restricted to the optimisation of traffic between an individual MNN
   and an individual CN, and can be established on an MNP-CN prefix
   basis.  The CRON mechanism aims at providing the flexibility required
   to support this granularity.  Each BU contains the MNP prefix/MNN
   address information in the Mobile Network Prefix Options and the CN
   address/prefix information in the Correspondent Router Prefix Option.

   The CR should be able to validate the CoA ownership claimed by the MR
   (that is, that the MR is actually reachable at its CoA).  Depending
   on the considered use case, it might not be enough to rely on ingress
   filtering techniques at the access network.  In those scenarios, the
   MR MUST test the CoA reachability following the Return Routability
   procedure (this would involve only the CoTI/CoT), as specified in
   [2].

   Once the CR has received and processed the BU message, it SHOULD send
   a Binding Acknowledgement message to the MR.  If no BA is received,
   the MR MAY retransmit BU messages as long as some rate limitation is
   applied.  The MR MUST stop retransmitting when it receives a BA.



Bernardos, et al.        Expires January 8, 2009               [Page 11]


Internet-Draft            CR-based RO for NEMO                 July 2008


   When an MR receives a BA message from a CR, the MR MUST validate the
   message according to some tests.  This needs further elaboration (TBD
   in future versions of this document).  Any BA not satisfying all of
   those tests MUST be silently ignored.

   When an MR receives a packet carrying a valid BA, the MR MUST examine
   the Status field of the BA.  If the status field indicates that the
   BU was accepted, the MR MUST update the corresponding entry in its
   Binding Update List to indicate that the Binding Update has been
   acknowledged.  The MR MUST then set up a bi-directional tunnel with
   the IPv6 address of the CR as the other end-point of the tunnel, and
   add the entries to its routing table required to make use of the
   established tunnel in the forwarding of packets that match all of the
   following rules:
   o  The IPv6 source address of the packet belongs to one of the IPv6
      prefixes contained in the Mobile Network Prefix options included
      in the BA message.  Note that this implies that source address
      based routing MAY be required in certain cases.
   o  The IPv6 destination address of the packet belongs to one of the
      IPv6 prefixes contained in the Correspondent Router Prefix options
      included in the BA message.


5.  Correspondent Router operation

5.1.  Conceptual Data Structures

   Correspondent Routers MUST maintain a Binding Cache (BC) of bindings
   with MRs.  This BC is similar to the one kept by CNs with RO support
   as defined in [2].  In addition to the fields contained in the BC
   defined for a CN, the CR needs also to maintain the following
   information:

   o  A flag specifying whether the entry is a Correspondent Router
      entry or not (applicable only on nodes which support also MIPv6
      RO, to differentiate from normal MIPv6 BCEs).
   o  Source IPv6 optimised prefix: this field contains the IPv6
      address/prefix of those nodes managed by the CR (i.e.  CNs) whose
      traffic is being optimised by using an MR-CR bi-directional tunnel
      with the MR.  There could be multiple instances of this field in
      the BCE.  These are basically the IPv6 addresses/prefixes included
      in the Correspondent Router Prefix options carried in the BU/BA
      signalling exchanged by the CR and the MR.
   o  Destination IPv6 optimised prefix: this field contains the IPv6
      address/prefix of those nodes (i.e.  MNNs) whose traffic is being
      optimised by using an MR-CR bi-directional tunnel with the MR.
      There could be multiple instances of this field in the BCE.  These
      are basically the IPv6 addresses/prefixes included in the Mobile



Bernardos, et al.        Expires January 8, 2009               [Page 12]


Internet-Draft            CR-based RO for NEMO                 July 2008


      Network Prefix options carried in the BU/BA signalling exchanged
      by the CR and the MR.
   o  The CR MAY have a policy database that contains information
      regarding which communications can be route optimised and which
      not.  It is up to the implementation the decision about the exact
      content of this database, as well as if it can be dynamically
      updated or it is pre-configured statically.

5.2.  Correspondent Router Binding

   When a CR receives a BU message from an MR, the CR MUST validate the
   message according to some tests.  This needs further elaboration (TBD
   in future versions of this document).  Any BU not satisfying all of
   those tests MUST be silently ignored.  Additionally, some other test
   MUST be performed (such as authorisation check, etc.).  If some of
   these tests fail, the CR SHOULD return a BA to the MR including an
   appropriate value in the Status field (TBD).

   When a CR receives a packet carrying a valid BU, and all the tests
   are successful, the CR SHOULD add an entry on its BC and return a BA
   to the MR, setting the Status field to a value indicating success.
   This BA would also include all the Mobile Network Prefix and
   Correspondent Router Prefix Options included in the BU message.  The
   CR MUST then set up a bi-directional tunnel with the MR's CoA as the
   other end-point of the tunnel, and add the entries in its routing
   table required to make use of this tunnel in the forwarding of
   packets that match all of the following rules:
   o  The IPv6 source address of the packet belongs to the one of the
      IPv6 prefixes contained in the Correspondent Router Prefix options
      contained in the BA message.  Note that this implies that source
      address based routing MAY be required in certain cases.
   o  The IPv6 destination address of the packet belongs to the one of
      the IPv6 prefixes contained in the Mobile Network Prefix options
      included in the BA message.

5.3.  Intercepting Packets from a Correspondent Node

   A Correspondent Router needs to intercept packets sent by all CNs
   from which it has a BCE, since the CR has to send those packets
   through the established MR-CR bi-directional tunnel.  However,
   depending on the topological location of the CR, different operation
   may be needed in order to intercept packets from CNs.

   If the CR is the gateway of all the CNs it manages -- that is, it is
   always on the path between all CNs and any other node outside the
   domain --, nothing needs to be done in order to intercept packets
   that have to be route optimised, since all packets are already
   received by the CR.



Bernardos, et al.        Expires January 8, 2009               [Page 13]


Internet-Draft            CR-based RO for NEMO                 July 2008


   If the CR is not the gateway of all the CNs, in order to intercept
   those packets that need to be route optimised, the CR MUST inject
   routes advertising the corresponding MNPs within the domain of the
   CR.  This would make routers in the domain to forward the packets
   addressed to those MNPs to the CR, so it can forward them to the
   right MRs using the established MR-CN bi-directional tunnel.  Further
   attention is needed in order to come up with a flexible mechanism to
   enable a CR in a domain receive only those packets that need to be
   route optimised, without impacting on the routing of the rest of the
   packets -- that should follow the normal route (towards the
   respective home networks) --.  Mechanisms enabling that behaviour are
   subject of future versions of this document.


6.  Security Considerations

   CRON assumes that trust relationships exist between the MR/HA and the
   CR, allowing IPsec/IKE to be used to secure Binding Updates.
   Certificates are used to prove ownership of prefixes by MRs and CRs.
   The Return Routability mechanism is used by the MR to prove CoA
   ownership to the CR.

   Given that CRON enables to change routing state at certain nodes, a
   more detailed security analysis is needed (TBD in a future version of
   this document).


7.  IANA Considerations

   This document requires IANA to assign a number for a new Mobility
   Option type (Correspondent Router Prefix).


8.  Acknowledgements

   This draft collects input from many previous works.  The concept of
   Correspondent Router is known since at least 2002.  Authors of the
   present document therefore would like to thank and acknowledge
   authors of these previous works.

   The work of Carlos J. Bernardos and Maria Calderon has been also
   partly supported by the Spanish Government under the POSEIDON
   (TSI2006-12507-C03-01) project.


9.  References





Bernardos, et al.        Expires January 8, 2009               [Page 14]


Internet-Draft            CR-based RO for NEMO                 July 2008


9.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [3]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [4]   Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
         "Multiple Care-of Addresses Registration",
         draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008.

9.2.  Informative References

   [5]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [6]   Ernst, T. and H-Y. Lach, "Network Mobility Support
         Terminology", RFC 4885, July 2007.

   [7]   Ernst, T., "Network Mobility Support Goals and Requirements",
         RFC 4886, July 2007.

   [8]   Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
         Route Optimization Problem Statement", RFC 4888, July 2007.

   [9]   Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
         Route Optimization Solution Space Analysis", RFC 4889,
         July 2007.

   [10]  Zhao, F., "NEMO Route Optimization Problem Statement and
         Analysis", draft-zhao-nemo-ro-ps-01 (work in progress),
         February 2005.

   [11]  Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route
         Optimization models in the Nemo Context",
         draft-thubert-nemo-ro-taxonomy-04 (work in progress),
         February 2005.

   [12]  Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
         draft-wakikawa-nemo-orc-01 (work in progress), November 2004.

   [13]  Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization
         Requirements for Operational Use in Aeronautics and  Space



Bernardos, et al.        Expires January 8, 2009               [Page 15]


Internet-Draft            CR-based RO for NEMO                 July 2008


         Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02
         (work in progress), May 2008.

   [14]  Baldessari, R., Ernst, T., and M. Lenardi, "Automotive Industry
         Requirements for NEMO Route Optimization",
         draft-ietf-mext-nemo-ro-automotive-req-00 (work in progress),
         February 2008.

   [15]  Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer
         Electronics Requirements for Network Mobility Route
         Optimization", draft-ng-nemo-ce-req-02 (work in progress),
         February 2008.

   [16]  Bauer, C. and S. Ayaz, "ATN Topology Considerations for
         Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work
         in progress), July 2008.

   [17]  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
         Multihoming in Network Mobility Support", RFC 4980,
         October 2007.

   [18]  Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
         Exploration Protocol for IPv6  Multihoming",
         draft-ietf-shim6-failure-detection-13 (work in progress),
         June 2008.

   [19]  Bernardos, C., Soto, I., Calderon, M., Boavida, F., and A.
         Azcorra, "VARON: Vehicular Ad-hoc Route Optimisation for
         NEMOO", Computer Communications, Volume 30, Issue 8, Pages
         1765-1784 , June 2007.


Appendix A.  Analysis of CRON and the Aeronautics requirements

   This appendix looks at the Aeronautics requirements described in [13]
   and analyses how CRON fits each of them.  If a certain requirement
   cannot be fulfilled by CRON as it is described in this document,
   possible modifications/extensions are also considered.  This analysis
   aims at understanding if a CR-based solution could be a good
   candidate to be used as a NEMO RO solution for the aeronautics
   scenario.

A.1.  Req1 - Separability

   This requirement basically states that "an RO scheme MUST support
   configuration by a per-domain dynamic RO policy database.  Entries in
   this database can be similar to those used in IPsec security policy
   databases in order to specify either bypassing or utilizing RO for



Bernardos, et al.        Expires January 8, 2009               [Page 16]


Internet-Draft            CR-based RO for NEMO                 July 2008


   specific flows".

   This requirement is fulfilled by CRON, since the Route Optimisation
   can be performed on an MNN-CN basis (MNP-CN prefix optimisations can
   also be performed) and the decision about which communications are
   optimised is taken by the MR.  Therefore, different approaches can be
   implemented in the MR (it is open to the particular CRON
   implementation how to do it) to take this decision: static and
   dynamic policies (using a protocol to update MR's policies),
   decisions based on current load of the MR, etc.

A.2.  Req2 - Multihoming

   This requirement states that "an RO solution MUST support an MR
   having multiple interfaces, and MUST allow a given domain to be bound
   to a specific interface.  It MUST be possible to use different MNPs
   for different domains".

   Since CRON achieves the NEMO RO by performing bindings with different
   CRs, setting up bi-directional tunnels between a CR and an MR's CoA,
   it is possible to support multi-interfaced MRs and use different MNPs
   for different domains.  Besides, CRON can potentially benefit
   directly from any mechanism developed for MIPv6 to support multiple
   interfaces (such as [4]).

   We should also mention that although CRON can benefit from
   multihoming solutions developed within the MEXT WG, multihoming
   issues in Network Mobility [17] should be tackled specifically by a
   general NEMO multihoming framework.  Since CRON does not modify in
   any way the NEMO Basic Support operation, it will also be compatible
   with such a general NEMO multihoming solution.

A.3.  Req3 - Latency

   This requirement says: "while an RO solution is in the process of
   setting up or reconfiguring, packets of specified flows MUST be
   capable of using the MRHA tunnel".

   This means that an RO solution MUST NOT prevent data packets from
   being forwarded through the MRHA bi-directional tunnel while the
   required RO operations are being performed.  This requirement is also
   fulfilled by CRON, since while the MR performs all the required
   signalling (i.e.  CoTI/CoT and BU/BA), communications aimed at be
   route optimised still use the MRHA tunnel.







Bernardos, et al.        Expires January 8, 2009               [Page 17]


Internet-Draft            CR-based RO for NEMO                 July 2008


A.4.  Req4 - Availability

   This requirement states that "an RO solution MUST be compatible with
   network redundancy mechanisms and MUST NOT prevent fall-back to the
   MRHA tunnel if an element in an optimized path fails".  It is also
   stated that "an RO mechanism MUST NOT add any new single point of
   failure for communications in general".

   On the one hand, current NEMO Basic Support protocol [3] does not
   fulfil that today, and therefore needs additional work to be carried-
   out.  On the other hand, CRON brings the role of the Correspondent
   Router into the picture.  Therefore, a new potential point of failure
   is added: the CR.

   If a CR fails, communications being optimised would obviously be
   disrupted.  Although CRON currently does not address this issue,
   additional mechanisms -- such as deploying several redundant or back-
   to-back CRs, or designing/reusing existing protocols to keep the RO
   state of several CRs synchronised -- might be used here.  In any
   case, by using short lifetimes, the potential negative effect of such
   a CR failure may be reduced.  Besides, protocols such as REAP [18]
   can be used to effectively detect failures between the MR and the CR
   (not only caused by a CR failure, but also by a problem on the path
   between them).

   In case an MR fails, if it is the only one deployed at the NEMO, this
   would obviously disrupt established connections.  In the case of a
   multiple-MR NEMO, additional mechanisms would be required in order to
   guarantee that route optimised communications managed by a particular
   MR would survive in case this MR fails.  Again, although CRON
   currently does not address this issue, additional mechanisms -- such
   as deploying back-to-back MRs in aircrafts or designing/reusing
   existing protocols to keep the RO state of several MRs synchronised
   -- might be used here.

A.5.  Req5 - Packet Loss

   This requirement says that "an RO scheme SHOULD NOT cause either loss
   or duplication of data packets during RO path establishment, usage,
   or transition, above that caused in the NEMO basic support case.  An
   RO scheme MUST NOT itself create non-transient losses and
   duplications within a packet stream".

   The use of CRON does not add any significant delay nor causes any
   additional packet loss compared to the normal NEMO Basic Support
   protocol handover.  It is worth to mention that some signalling is
   required to update the bindings at the CRs, and although this can be
   done in parallel with the Home Registration, a small delay can be



Bernardos, et al.        Expires January 8, 2009               [Page 18]


Internet-Draft            CR-based RO for NEMO                 July 2008


   introduced because of this.  Micro-mobility techniques can be used if
   required to mitigate that effect, if required.

A.6.  Req6 - Scalability

   This requirement says that "an RO scheme MUST be simultaneously
   usable by the MNNs on hundreds of thousands of craft without
   overloading the ground network or routing system.  This explicitly
   forbids injection of BGP routes into the global Internet for purposes
   of RO".

   There are different aspects that may affect to the scalability of
   CRON:

   o  Memory consumption at the MR.  CRON needs some additional
      information to be stored at the MR, such extended BUL.  The
      required memory to store this extended BUL is relatively small and
      grows linearly with the number of different route optimised
      communications.
   o  Processing load at the MR.  CRON requires more complex routing
      operations at the MR.  The routing table of an MR performing RO
      operations would have more entries than a normal RFC 3963 MR, the
      MR should set-up and maintain more bi-directional tunnels, and
      source address based routing might be required.  However, all of
      these operations do not add significant load, and in any case
      complexity grows linearly with the number of different route
      optimised communications.
   o  Processing load and memory consumption at the CR.  The same
      reasoning applies here.  Besides, multiple CRs can be deployed on
      sites supporting a high load of route optimised traffic.
   o  Impact on the global routing system.  CRON does not have any
      impact on the global routing tables, and therefore it does not
      introduce any routing scalability issue, even with large
      deployments.

A.7.  Req7 - Efficient Signaling

   This requirement is related to the additional signalling required by
   a NEMO RO solution, and basically states that "an RO scheme MUST be
   capable of efficient signaling in terms of both size and number of
   individual signaling messages and the ensemble of signaling messages
   that may simultaneously be triggered by concurrent flows".

   With CRON, the amount of required signalling depends on the number
   and type of communications that are optimised.  Since almost any
   granularity is supported by CRON, in those cases in which individual
   MNN-CN optimisations are not required -- and MNP-CN prefix ones are
   used instead -- the amount of signalling needed is very small.  In



Bernardos, et al.        Expires January 8, 2009               [Page 19]


Internet-Draft            CR-based RO for NEMO                 July 2008


   order to perform an optimisation (generally speaking, a MNP-CN prefix
   optimisation), a BU/BA message exchange is required (plus probably a
   CoTI/CoT exchange to test MR's CoA reachability).

A.8.  Req8 - Security

   This requirement is different depending on the considered traffic
   domain.  For ATS/AOS domains, there are three sub-requirements: "a)
   The RO scheme MUST NOT further expose MNPs on the wireless link than
   already is the case for NEMO basic support; b) The RO scheme MUST
   permit the receiver of a BU to validate an MR's ownership of the CoAs
   claimed by an MR; and c) The RO scheme MUST ensure that only
   explicitly authorized MRs are able to perform a binding update for a
   specific MNP".  For the PIES domain: "there are no additional
   requirements beyond those of normal Internet services and the same
   requirements for normal Mobile IPv6 RO apply".

   CRON meets all aforementioned requirements. a) Since BU/BA signalling
   is sent protected with IPsec, MNPs are not exposed, b) the MR's CoA
   ownership can be tested by means of the RR procedure (in particular,
   by means of the CoTI/CoT exchange), and c) by the use of certificates
   and local policies, only authorised MRs can perform a binding for a
   specific MNP.

A.9.  Req9 - Adaptability

   This requirement states that "applications using new transport
   protocols, IPsec, or new IP options MUST be possible within an RO
   scheme".

   Since CRON makes use of a bi-directional tunnel between the MR and
   the CR, encapsulating data packets into the tunnel -- without
   performing any modifications to them --, this requirement is also
   met.

A.10.  Des1 - Configuration

   This requirement is not considered as a strict one, and basically
   states that "it is desirable that a NEMO RO solution be as simple to
   configure as possible and also easy to automatically disable if an
   undesirable state is reached".

   CRON configuration is not detailed in this document, since it is open
   to implementation.  However, even if complex policies are used to
   determine which communication are route optimised, CRON configuration
   would be as simple as configuring today's firewalls.  Some
   coordination is needed though to configure properly MRs, CRs -- and
   likely additional infrastructure (such as CR-resolvers) -- in order



Bernardos, et al.        Expires January 8, 2009               [Page 20]


Internet-Draft            CR-based RO for NEMO                 July 2008


   to effectively enable RO to take place.

A.11.  Des2 - Nesting

   This requirement is not considered as a strict one, and basically
   states that "it is desirable if the RO mechanism supports RO for
   nested MRs".

   CRON, as it is described in this document, does not provide RO
   capabilities for nested MRs.

A.12.  Des3 - System Impact

   This requirement is not considered as a strict one, and basically
   states that "low complexity in systems engineering and configuration
   management is desirable in building and maintaining systems using the
   RO mechanism".

   CRON requires changes on the MR, and the deployment of additional
   entities: the CRs (although this might be done by simply updating the
   software of some existing routers at the CN domains to support the CR
   functionality).  The deployment of CRON also requires trust
   relationships between MRs/HAs and CRs to be in place.  In order to
   help MRs in the discovery of CRs, the deployment of external
   services, such as CR-resolvers, might be required.

A.13.  Des4 - VMN Support

   This requirement is not considered as a strict one, and basically
   states that "it is strongly desirable for VMNs to be supported by the
   RO technique, but not strictly required".

   CRON is aimed at bypassing the MR's HA, but it does not avoid the
   traversal of VMNs' HAs.  Therefore, a completely optimal path is not
   follow by packets of VMNs (only the MR's HA is bypassed).

A.14.  Des5 - Generality

   This requirement is not considered as a strict one, and basically
   states that "an RO mechanism that is "general purpose", in that it is
   also readily usable in other contexts outside of aeronautics and
   space exploration, is desirable".

   Correspondent Router approaches were designed as general NEMO RO
   frameworks, not being focused to address any particular scenario.
   Current CRON design has been tailored to address the particular
   scenario of aeronautics and space exploration.  However, CRON -- with
   or without modifications/extensions -- could also be considered as a



Bernardos, et al.        Expires January 8, 2009               [Page 21]


Internet-Draft            CR-based RO for NEMO                 July 2008


   solution for other scenarios such as the vehicular [14] one.
   Besides, extensions to enable the use of CRON without the requiring
   the deployment of certificates -- using techniques similar to the
   ones described in [19] -- are currently being analysed and will be
   included in future revisions of this document.  These extensions
   would enable extending the applicability of CRON to other scenarios
   such as the consumer electronics one [15].


Authors' Addresses

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es


   Maria Calderon
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 8780
   Email: maria@it.uc3m.es


   Ignacio Soto
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 5974
   Email: isoto@it.uc3m.es












Bernardos, et al.        Expires January 8, 2009               [Page 22]


Internet-Draft            CR-based RO for NEMO                 July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Bernardos, et al.        Expires January 8, 2009               [Page 23]