One document matched: draft-bernardos-mext-aero-nemo-ro-sol-analysis-00.txt
MEXT Working Group C. Bernardos
Internet-Draft UC3M
Intended status: Informational October 27, 2008
Expires: April 30, 2009
Analysis on how to address NEMO RO for Aeronautics Mobile Networks
draft-bernardos-mext-aero-nemo-ro-sol-analysis-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 April 30, 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.
There are currently a set of well defined NEMO Route Optimization
requirements for Operational Use in Aeronautics and Space
Bernardos Expires April 30, 2009 [Page 1]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
Exploration, from which solutions should be based on. This document
analyses how the problem of NEMO RO for Aeronautics Mobile Networks
might be tackled, in a way as generic as possible, trying to identify
those open questions and deployment considerations that need to be
addressed.
The main goal of this document is to foster the discussion about
aeronautics NEMO RO solution space within the MEXT WG.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Space analysis . . . . . . . . . . . . . . . . . . . 3
3. Design issues/questions/trade-offs . . . . . . . . . . . . . . 6
3.1. Where are the correspondent entities located? . . . . . . 7
3.2. Who administratively manages the correspondent
entities? . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Which kind of addresses are gonna be used and who own
them? . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. How many correspondent entities are needed to globally
perform NEMO RO? . . . . . . . . . . . . . . . . . . . . . 9
3.5. What trust relationships are needed? . . . . . . . . . . . 10
3.6. Is the solution flexible enough to allow the
participation of the end-nodes (CNs and/or MNNs)? . . . . 11
3.7. Does the solution allow for a hierarchical scheme? . . . . 11
3.8. What is the target protocol complexity? . . . . . . . . . 12
3.9. How is routing performed within the ATN? . . . . . . . . . 12
3.10. Does the solution allow for implementing
legal/political/economical requirements? . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Bernardos Expires April 30, 2009 [Page 2]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
1. Introduction
This document assumes that the reader is familiar with the
terminology related to Network Mobility [4] and [5], and with the
Mobile IPv6 [2] and NEMO Basic Support [3] protocols.
The MEXT WG is currently chartered to work on three use cases for
route optimization of network mobility, namely aeronautics [6],
vehicular [7] and consumer electronics [8]. The work on the
requirements for the aeronautics use case seems to be mature enough
at this point to start discussing about solutions. This document is
an initial attempt aimed at fostering discussion on solutions, by
presenting a general framework of how a solution for the aeronautics
use case could look like, and identifying and highlighting relevant
questions, issues and deployment models that need to be taken care of
during the solution definition process.
The requirements for the aeronautics use case [6] differentiate among
three different domains of interest: Air Traffic Services (ATS), Air
Operational Services (AOS) and Passenger Information and
Entertainment Services (PIES). Besides, two kind of requirements are
identified: required (minimal properties that a solution must
possess) and desirable (difficult to quantify or not immediately
needed requirements) characteristics. Since the PIES domain is not
critical to safety-of-life, but mostly involves added comfort and
business services to passengers, this domain has not been taken into
account as input for the required characteristics.
Due to the very different nature of the required and desirable
characteristics, and the importance of the former ones, this document
only analyzes how a solution for ATS/AOS would look like.
2. Solution Space analysis
In this section we try to outline the general lines of a NEMO Route
Optimization solution for the aeronautics use case (ATS/AOS domains),
based on the set of requirements described in [6], which we summarize
next:
o Separability: an RO solution MUST support configuration by using a
dynamic RO policy database, so RO for certain flows can be
disabled/enabled. A granularity level similar to the one of IPsec
security policy databases is expected to be supported.
o Multihoming: an RO solution MUST support multi-interfaced MRs, and
it MUST allow the use of different interfaces (and also different
MNPs) for different domains.
Bernardos Expires April 30, 2009 [Page 3]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
o Latency: an RO solution MUST allow packets to use the MRHA tunnel
while setting up or reconfiguring the RO path.
o Availability: an RO solution MUST NOT prevent to fall-back using
the default MRHA tunnel if the RO path fails for whatever reason.
This basically also means that an RO solution MUST NOT introduce
any new single point of failure for the communications.
o Packet Loss: an RO solution SHOULD NOT cause either additional
loss or duplication of data packets due to the use of RO, above
that caused in the NEMO basic default solution.
o Scalability: an RO solution MUST be simultaneously usable by
hundreds of thousands of crafts without overloading the ground
network or the routing system.
o Efficient Signaling: an RO solution MUST be efficient in terms of
the number of required signaling messages, and avoid signaling
storms as a result of providing multiple ongoing flows with RO
following a handover.
o Security: an RO solution MUST NOT expose MNPs on the wireless
egress link, MUST allow the receiver of BUs to validate CoA
ownership, and MUST ensure that only explicitly authorized MRNs
are able to send a BU for a specific MNP.
o Adaptability: an RO solution MUST NOT prevent applications from
using transport protocols, IPsec or new IP options.
o Although it is not explicitly listed as a required characteristic
-- but only suggested in [6] --, it seems to be widely accepted
that modifications to CNs MUST NOT be required by an RO solution.
From this list of requirements, a first conclusion that can be
obtained is that a solution for the aeronautics NEMO RO use case MUST
NOT require changes on the CNs in order to correctly operate, that
is, a solution MUST provide certain level of RO with legacy IPv6 CNs.
This means that the solution would likely rely on a set of entities
at the infrastructure, performing the RO function between them or/and
also the MR.
In a glimpse, a solution along the lines mentioned before would
operate as follows (Figure 1): an optimized route between a mobile
network deployed in a craft and a CN (or set of CNs) is set-up (upon
some sort of trigger/policy) between two (or more in general terms)
NEMO RO correspondent entities. These correspondent entities should
be located -- in order to provide an optimized route as shorter as
possible -- close to the mobile network and/or the CN. It should be
noted that one of these correspondent entities may be collocated
within the MR. A tunnel between the correspondent entities (or a
chain/nesting of tunnels, in case several correspondent entities are
involved in the same optimized route) is established, so data traffic
between the mobile network and the CN (or set of CNs) can be routed
through this shorter route (compared with the default MRHA one). It
might be the case that certain additional operations are needed in
Bernardos Expires April 30, 2009 [Page 4]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
order to ensure that traffic sent/received by the CN (or by the
mobile network) is routed through the correspondent entities, so they
can forward packets using the optimized route.
---------
| HA_MR |
---------
|
|
(-*-*-*-*+*-*-*-*-)
-*- -*-
( )
-*- ATN -*- ------
( ) | CN |
( --------- ) ------
( | NROCE |........)--+ |
( /./------- ) |====?=====?==
( /./ ) |
-*- /./ -*- ------
( --------- ) | CN |
-*- | NROCE | -*- ------
( --------- )
-*- . -*-
( . )
-*- . -*-
-*+*-
|
|
------ ---------------------------------------
| AR | | AR: Access Router |
------ | CN: Correspondent Node |
| | MR: Mobile Router |
===?========== | HA_MR: MR's Home Agent |
| | MNP: Mobile Network Prefix |
------ | MNN: Mobile Network Node |
| MR | | NROCE: NEMO RO Correspondent Entity |
------ ---------------------------------------
|
===?========?====(MNP)
| |
------- -------
| MNN | | MNN |
------- -------
Figure 1: Correspondent entity-based solution architecture
This approach, based on the use of correspondent network entities
that are in charge of performing the NEMO RO, seems to be the
Bernardos Expires April 30, 2009 [Page 5]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
solution that has received more positive feedback from the MEXT WG so
far. This solution -- as described in this document -- is very
general and leaves (on purpose) many aspects open/undefined.
Depending on the particular design decisions that can be taken,
completely different solutions might be the outcome. For example,
there are currently two proposed solutions that implement the
correspondent entity-based concept in different ways: the global Home
Agent to Home Agent (HAHA) [9], [10], and the Correspondent Router
based RO for NEMO (CRON) [11].
Since different design decisions might result into completely
different solutions, each of them meeting different requirements and
providing different features, it is very important to understand the
impact of the related design decisions, as well as the involved
trade-offs, when designing a NEMO RO solution for the aeronautics use
case. It is also important to look at the deployment issues derived
from the particular characteristics of the Aeronautical
Telecommunications Networks (ATNs) [12]. The next section of this
document is aimed at identifying the different important design
aspects, deployment issues and resulting trade-offs when considering
a correspondent entity-based NEMO RO solution. The goal of such an
exercise is to help the MEXT WG in the design of the NEMO RO solution
for the aeronautics use case.
3. Design issues/questions/trade-offs
In this section, we attempt to identify relevant design issues,
questions and involved trade-offs when considering a correspondent
entity-based NEMO RO solution, by asking the following questions:
1. Where are the correspondent entities located?
2. Who administratively manages the correspondent entities?
3. Which kind of addresses are gonna be used and who own them?
4. How many correspondent entities are needed to globally perform
NEMO RO?
5. What trust relationships are needed?
6. Is the solution flexible enough to allow the participation of the
end-nodes (CNs and/or MNNs)?
7. Does the solution allow for a hierarchical scheme?
8. What is the target protocol complexity?
Bernardos Expires April 30, 2009 [Page 6]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
9. How is routing performed within the ATN?
10. Does the solution allow for implementing legal/political/
economical requirements?
3.1. Where are the correspondent entities located?
A first important question is where the correspondent entities are
located.
One option is to place the correspondent entities at the gACSPs. In
this case the optimized path would have at least one end-point
(depending on whether the solution involves two correspondent
entities at the infrastructure or one entity at the infrastructure
and the MR) at the gACSP. This may be not good enough from a
performance point of view, since the farther the correspondent
entities are from the communication end-points (i.e., the mobile
network and the CNs) the more likely the resulting path would be less
optimal.
There are some potentially relevant questions related to placing
entities at the gACSPs:
o can an MR get connectivity from two different gACSPs?
o is it possible that the same MR needs to make use of correspondent
entities placed at different gACSPs?
o would it be possible/required that an RO path is set-up between
correspondent entities belonging to two different gACSPs? If so,
the different routing policies that gACSPs might implement are
relevant, as we analyze later.
Another potential configuration is to place the correspondent
entities at the ANSPs. This configuration would allow to have one
end-point of the optimization close to the CNs (for the ATS scenario)
and therefore would result in paths that in general would be closer
to the optimal case. On the other hand, this approach would require
more correspondent entities to be deployed, therefore eventually
increasing the complexity of the solution. Besides, a solution that
only places the infrastructure correspondent entities at the ANSPs
would require the MR being the other correspondent entity in the NEMO
RO process, since an MR might get connectivity through a gACSP, or
through an lACSP that is not an ANSP. In the AOS scenario, this
configuration might not work, since AOS CNs might not get
connectivity through an ANSP, and therefore a correspondent entity
should be deployed somewhere else.
In those communication scenarios in which the MR is attached to an
ANSP access network and it is communicating with a CN also attached
to the same ANSP, placing the correspondent entities at the ANSP (or
Bernardos Expires April 30, 2009 [Page 7]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
collocated within the MR) provides the additional advantage that
these communications would survive failures on the gACSPs to which
the ANSP gets connectivity from. This brings the following question:
o if a craft attached to an ANSP access network is communicating
with a CN attached to the same ANSP, is it required for the NEMO
RO solution to survive when the link of the ANSP to its gACSP goes
down? or put in a different way, would it be OK for such a
communication to be broken? It should be noted that the default
MRHA path used by the NEMO Basic Support protocol would likely
fail in this scenario.
Another approach is to deploy infrastructure correspondent entities
at the networks where CN are attached (these networks might be ANSPs
in some scenarios) and at MRs. This would provide shorter paths, at
the cost of higher complexity.
Last, a solution might not assume any particular placement of the
correspondent entities, i.e. they can be located anywhere. This
assumption, however, might not hold, depending on different aspects
-- such as security and addressing (for example if prefixes used in
ATS cannot leak to the Internet, leading to ATS traffic traversing
the public Internet).
3.2. Who administratively manages the correspondent entities?
It is also important to analyze who will be the players than manage
the correspondent entities, since this might have a critical impact
on the trust relationships that can be assumed among the different
correspondent entities.
One first scenario is the one in which all the correspondent entities
are managed by the same administrative entity. This compresses both
the case of correspondent entities deployed and managed by the
airline company, and the case of a global ACSP providing the
correspondent entities for airlines with an agreement with the ACSP.
The obvious advantage of this scenario is that it makes security and
authentication easier, since all the correspondent entities belong to
the same administrative domain. However, this does not mean that
this scenario is excluded from having trust issues, since a
particular solution might require to inject routes in some parts of
the network (e.g., correspondent entities owned by an airline and
placed in networks not managed by the airline, anycast routing,
etc.), and this could require additional trust relationships.
A second scenario is that in which correspondent entities are managed
by different administrative domains. This approach has the advantage
that it provides additional flexibility, but it has the drawback of
requiring additional trust agreements in order to enable NEMO RO to
Bernardos Expires April 30, 2009 [Page 8]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
be provided in a secure way. Depending on the particular solution,
these additional trust relationships may include those that are
necessary to enable anycast routing, route injection or strong state
synchronization, among others. These are examples of functions that
are usually not easy to achieve across different domains.
For AOS, it seems assumable to deploy a correspondent entity close
the the CNs, and then perform RO between this entity and the MR,
since both entities are operated by the same organization (therefore,
existence of certificates between these nodes could be expected).
The ATS case is different, and should be analyzed carefully.
Although some trust may exist between a correspondent entity
belonging to an ANSP and another correspondent entity (e.g., one
deployed at the aircraft, or one deployed at one gACSP), assuming the
existence of certificates or strong trust relationships is not clear
at this point [12]. This brings the following question:
o which trust relationships are expected? this will be analyzed in
further detail in another subsection.
3.3. Which kind of addresses are gonna be used and who own them?
Addressing aspects might be relevant for the design of a NEMO RO
solution. Some related questions are the following:
o are there gonna be reserved blocks of addresses for aeronautical
use (i.e. addressing used to derive MNPs from)?
o can prefixes used to derive the MNPs configured at the crafts leak
on the routing tables of the public Internet? can ATS/AOS traffic
traverse the public Internet?
o what kind of addressing is gonna be used for ATS and AOS? would it
be the same kind of addressing?
o is it fine to use PA addresses to derive the MNPs configured at
the crafts or is it a requirement to use PI addresses (delegated
to the airline, to enable provider independency)? One possible
solution design is that MNPs are derived from the addressing of a
gACSP which deploy several correspondent entities to perform NEMO
RO, but this scenario would tie the airline to keep using the same
provider.
3.4. How many correspondent entities are needed to globally perform
NEMO RO?
Another important aspect that should be taken into account is the
number of correspondent entities that would be required to perform
NEMO RO efficiently. There are many aspects that may have an impact
on the number of required correspondent entities, such as:
o Location of the correspondent entities. If a solution is based on
placing correspondent entities very close to the CNs this might
require an entity per CN network (e.g., per ANSP). Solutions
Bernardos Expires April 30, 2009 [Page 9]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
relying on correspondent entities located at gACSPs may require
less entities to be deployed.
o Who owns/manages the correspondent entities. Depending on the
particular solution, it could happen that each airline has to
deploy its own correspondent entities, thus requiring a set of
correspondent entities per airline.
o Required level of RO. Of course, depending on the optimization
levels that are required to be achieved, the location and number
of correspondent entities would change. If certain amount of
additional delay are allowed, it is expected that less entities
would be needed, since there is usually a trade-off between the
number and location of correspondent entities, and the reduction
of the delay due to the optimized path.
3.5. What trust relationships are needed?
Trust relationships are a quite important aspect to be analyzed. As
it has been described in this document, a solution based on the
deployment of correspondent entities may take many different forms,
depending on the design decisions and the deployment assumptions that
are followed. Most of the design decisions would have an impact or
would be constrained by the trust relationships that are in place
among the different players involved in the NEMO RO.
A solution based on the establishment of an optimized path between
two or more correspondent entities inherently requires those entities
to have strong trust relationships with the end-points of the
communications, since they are providing an alternative -- over the
MRHA default path -- route for their communication. Therefore, both
MNNs and CNs MUST have some form of trust relationship with the
correspondent entities, to allow the latter set-up an optimized route
for their traffic (on their behalf). As an example, both the MR and
the HA of a particular mobile network clearly have the required trust
relationship with the MNNs of the mobile network, and therefore they
could take part of an optimization mechanism. Other entities but the
MR and its HA would need additional trust relationships in place in
order to take part of a NEMO RO solution.
The correspondent entities involved in a NEMO RO solution MUST also
have some trust relationship between them, allowing them to
authenticate each other.
Additionally, correspondent entities involved in an RO attempt MUST
be able to show each other that they are authorized to send and
receive packets originated/destined to the nodes (MNNs or CNs) they
are providing RO with. As an example, let's assume a particular
solution in which there are two correspondent entities, one placed
close to the mobile network, and the other placed close to the CN.
Bernardos Expires April 30, 2009 [Page 10]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
In this example, the entity close to the mobile network should be
able to show to the one close to the CN that it is authorized to
send/received packets originated/destined to the MNNs of that
particular mobile network. It should be noted that the same kind of
authorization is required and provided when the NEMO Basic Support
protocol is used (i.e. the MR has to be authorized to set-up a tunnel
with its HA to exchange packets, and both MR and HA have to
authenticate each other before setting up the tunnel).
Correspondent entities MUST also be authorized to inject the routes
(if any) required to get the packets that are subject of being route
optimized. The simpler case is that in which a correspondent entity
is the default router of the MNNs (i.e. the MR) or the CNs, since in
this scenario nothing is required to make MNNs/CNs forward to the
correspondent entity their traffic, and therefore this entity is
inherently authorized to forward that traffic. Other kind of
solutions, in which the correspondent entities are not collocated
with the MR and the default router of the CN might require the
correspondent entities to inject routes within a certain portion of
the network. This might be hard to achieve across different domains.
The location and ownership of the correspondent entities would likely
have a great impact on the potentially required trust relationships.
Therefore, trust and location issues have to be simultaneously
considered.
3.6. Is the solution flexible enough to allow the participation of the
end-nodes (CNs and/or MNNs)?
Supporting legacy end-nodes (MNNs and CNs) seems to be a required
characteristic, although it is not explicitly listed as that in [6].
That means that a solution MUST NOT require changes neither at the
MNNs nor at the CNs to operate. However, that does necessary imply
that a particular solution cannot benefit from inserting changes on
some specific MNNs and/or CNs. In other words, a solution could
provide the option of collocating the correspondent entity function
within some MNNs and/or CNs -- in those scenarios in which these
modifications can be done. This brings the following question:
o is it permitted for a solution to collocate the correspondent
entity function within certain MNNs and/or CNs in case their
software upgrade is possible and that change brings operation
benefits?
3.7. Does the solution allow for a hierarchical scheme?
Solutions based on the deployment of correspondent entities that
perform the required route optimization operations may benefit from
adopting hierarchical schemes. This, for example, may help to reduce
Bernardos Expires April 30, 2009 [Page 11]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
signaling and produce faster handovers. Therefore, a consideration
that could also be taken into account when designing a solution is if
it would support a hierarchical mode of operation.
Another somehow related design consideration is the following: a
particular solution might benefit from deploying NetLMM-alike access
networks and collocating the functionality of the NEMO RO
correspondent entity with that of the LMA. This could improve the
overall performance, although at the prize of increasing the global
complexity and requiring ACSPs to be NetLMM-alike.
3.8. What is the target protocol complexity?
It is obvious that a solution should be as less complex as possible,
but there is always a trade-off involved: less complex solutions
usually provide less features/performance gains/etc., and the other
way around. There are some particular requirements of the
aeronautical NEMO RO scenario that would likely impact on the
solution complexity, and that should be taken into account.
For example, in order to meet the separability requirement [12],
correspondent entities in charge of performing the RO would have to
be able to decide whether a certain flow has to be optimized or not.
This could be done by local policies or explicit signaling. Even in
the case of local policies, some mechanisms would be needed to
support the update/modification of the policies. It seems likely
that it would be up to the mobile networks to decide what flows are
to be optimized and which not. Therefore, the costs associated to
meet the separability requirement would likely involve some sort of
signaling between the mobile networks and the correspondent entities
(at least to trigger the NEMO RO of a particular flow). This cost
should be evaluated and taken into account when designing a
correspondent entity-based solution.
3.9. How is routing performed within the ATN?
Routing policies and related issues within the ATN are an important
input to be considered when designing a correspondent entity-based
solution. Therefore, we should address the following questions:
o is it OK to have asymmetrical optimized routes? depending on the
design of the solution, it might be possible that some sort of
asymmetric routing appears.
o what are the routing policies followed by the ACSPs (especially
gACSPs)? do they do cold or hot-potato routing? cold-potato
routing may lead to very suboptimal routes under some particular
scenarios, even when a NEMO RO solution is used.
Bernardos Expires April 30, 2009 [Page 12]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
3.10. Does the solution allow for implementing legal/political/
economical requirements?
In some Internet scenarios, it is preferred that data traffic does
not traverse certain networks because of different reasons, such as
legal, political or economical ones. Is that also the case for the
aeronautics use case?. If so, it might be important to provide NEMO
RO solutions with the required mechanisms to implement the policies
that translate those potential legal/political/economical
requirements.
4. Security Considerations
This document analyzes a general approach to perform NEMO RO for the
aeronautics use case. As such, it identifies some security issues
that should be taken into account in the design of a concrete
solution.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgments
the author would like to thank Marcelo Bagnulo for his valuable
comments and support.
The work of Carlos J. Bernardos has been partly supported by the
Spanish Government under the POSEIDON (TSI2006-12507-C03-01) project.
7. References
7.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.
Bernardos Expires April 30, 2009 [Page 13]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
7.2. Informative References
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[6] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization
Requirements for Operational Use in Aeronautics and Space
Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02
(work in progress), May 2008.
[7] Baldessari, R., Ernst, T., Festag, A., and M. Lenardi,
"Automotive Industry Requirements for NEMO Route Optimization",
draft-ietf-mext-nemo-ro-automotive-req-01 (work in progress),
July 2008.
[8] 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.
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA
protocol", draft-thubert-mext-global-haha-00 (work in
progress), March 2008.
[10] Wakikawa, R., Shima, K., and N. Shigechika, "The Global HAHA
Operation at the Interop Tokyo 2008",
draft-wakikawa-mext-haha-interop2008-00 (work in progress),
July 2008.
[11] Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router
based Route Optimisation for NEMO (CRON)",
draft-bernardos-mext-nemo-ro-cr-00 (work in progress),
July 2008.
[12] Bauer, C. and S. Ayaz, "ATN Topology Considerations for
Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work
in progress), July 2008.
Bernardos Expires April 30, 2009 [Page 14]
Internet-Draft Aeronautics NEMO RO solution analysis October 2008
Author's Address
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
Bernardos Expires April 30, 2009 [Page 15]
Internet-Draft Aeronautics NEMO RO solution analysis October 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 Expires April 30, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 06:51:13 |