[MEXT] review of draft-ietf-mext-aero-reqs
Jari Arkko <jari.arkko@piuha.net> Thu, 07 February 2008 09:29 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: ietfarch-mip6-archive@core3.amsl.com
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498D93A7686; Thu, 7 Feb 2008 01:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level:
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TU-M97FxVUd; Thu, 7 Feb 2008 01:29:47 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8820D3A766B; Thu, 7 Feb 2008 01:29:47 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068DD3A765B for <mext@core3.amsl.com>; Thu, 7 Feb 2008 01:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ20uTItdMGu for <mext@core3.amsl.com>; Thu, 7 Feb 2008 01:29:44 -0800 (PST)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id F03363A765D for <mext@ietf.org>; Thu, 7 Feb 2008 01:29:43 -0800 (PST)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4C6EC198D08; Thu, 7 Feb 2008 11:31:14 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B44CD198AC0; Thu, 7 Feb 2008 11:31:13 +0200 (EET)
Message-ID: <47AACFDD.8030406@piuha.net>
Date: Thu, 07 Feb 2008 10:31:09 +0100
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: mext@ietf.org, draft-ietf-mext-aero-reqs@tools.ietf.org
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [MEXT] review of draft-ietf-mext-aero-reqs
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
I have reviewed this document. My detailed comments are further down. Overall, the document is well written and a good start for specifying what the aeronautics community needs. However, there are a number of issues that still need work: 1) To me, the main issue with airline network access is the extra continent roundtrip that is introduced if your tunnel has to be used and has to stay at the same server endpoint all the time. This issue needs emphasis among the various IMHO less important requirements. 2) The security requirements need significant work to specify what problems the RO solution must guard against. 3) Transport implications, separability, support VMNs, and some of the other specific requirements require further clarification. > Longer routes leading to increased delay and additional > infrastructure load - In aeronautical networks (e.g. using Plain > Old Aircraft Communication Addressing and Reporting System (ACARS) > or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are > often long due to ARQ mechanisms and underprovisioned radio links. > > Furthermore, for aeronautical communications systems that pass > through geosynchronous satellites, and for space exploration, the > propagation delays are also long. These delays combined with the > additional need to cross continents in order to transport packets > between ground stations and CNs means that delays are already > quite high in aeronautical and space networks without the addition > of an MRHA tunnel. The increased delays caused by MRHA tunnels > may be unacceptable in meeting Required Communication Performance > [8 <http://tools.ietf.org/html/draft-ietf-mext-aero-reqs-00#ref-8>]. Overall, I felt that the document talks about a large number of requirements, but fails to highlight the key problem which is talked about at the end of the above passage: as planes travel from one continent to another, having a stationary tunnel endpoint will eventually cause an additional continent roundtrip. > Increased packet overhead - Given the constrained link bandwidths > available in even future communications systems for aeronautics > and space exploration, planners are extremely adverse to header > overhead. Since any amount of available link capacity can be > utilized for extra situational awareness, science data, etc., > every byte of header/tunnel overhead displaces a byte of useful > data. Secondary issues like this are not very convincing (what about header compression, for instance?) and confuse the key problem. > Since for ATS, the MRs and MNNs are under regulatory control and are > actively tested and maintained, it is not unreasonable to assume that > special patches or software be running on these devices to enable > NEMO RO. In fact, since these devices are accessed by skilled > technicians and professionals, it may be acceptable even if complex > configuration is required for NEMO RO. Of course simplicity in setup > and configuration is desirable, however. What about CNs, is it reasonable to expect changes to them? > The set of CNs may be assumed to > all share the same network prefix. This seems unexpected. Why would we assume this? > 2.1.2. Airline Operational Services Domain This section talks about the airline's operational processes. What about the manufacturers, maintenance contract holders, etc -- I would expect that there will be some communication with them as well. > in the future, it is expected that the In-Flight > Entertainment (IFE) systems may receive movie refreshes of data > running into the gigabyte range. > This seems low. A single high-definition movie involves tens of gigabytes. If you are really talking about movies, I suspect these could be scheduled to be changed while in the airport. If you talk about current TV programs (news etc), it may be a different matter. Even then, I suspect one gigabyte is a small amount of data. > For the small number of messaging flows, > however, the CNs are geographically (but not necessarily > topologically) very close to the aircraft. It is not clear that this would be the case. We need to separate what happens at different layers. Recipients may indeed be close to you, but applications (chat, e-mail) typically go through central servers at the home site. > Due to the great size of the data stored on > these LFNs compared to the anemic bandwidth available air-to-ground, > these LFNs will probably not attempt to communicate off-board at all > during the course of a flight, but will wait to update their content > via either high-speed links are available on the ground, or via > removable media inserted by the flight crew. Hmm. It seems to me that there would be demand for downloading new data (e.g., current TV programming) if it were possible. I would not necessarily rule this out... > The RO solution should be optimized for > ATS and AOS needs, and consider PIES as a secondary concern. > > With this in consideration, the PIES domain is also the most likely > to utilize NEMO for communications in the near-term since > relatatively little regulations and beaurocracy are involved in > deploying new technology in this domain Are there legal interception requirements that would affect the passenger domain? Will these requirements affect what we need to do for RO? > It can be assumed that for manned spaceflight, at least, multiple MRs > will be present and on-line simultaneously for fast failover. These > will usually be multihomed over space links in diverse frequency > bands, and so multiple-prefixes can be expected, especially since > some links will be direct to ground stations while others may be > bent-pipe repeated through satellite relays like TDRSS. First, multiple prefixes on the access network that the MRs connect to, or multiple home prefixes that are presented to the mobile network nodes? These are very different... And if it is the latter, I'm not sure I fully understand why multiple prefixes are needed. > 3.1.1. Rationale for Aeronautics - Separability It is not clear to me why separability is needed as a requirement. Or at least it is unclear to me whether this refers to a functionality within NEMO or something relating to the ability to employ NEMO on a case-by-case basis. Presumably, you should be able to run NEMO, NEMO RO, and various different techniques on the different domains independently already today. Simply have some devices in the plane be under an MR that uses RO, some under an MR that does not, others that don't use NEMO at all, etc. I think it would be potentially harmful to try to integrate the different traffic domains under the same MR and NEMO connection. Particularly given the safety issues. > 3. Required Characteristics Should this document talk about the requirements related to transport effects from the use of RO? Or lack thereof... > If duplicating a small number of packets sent over > both the MRHA tunnel and the optimized path is possible until the > optimized path can be verified to function for a particular data > flow, then this could be sufficient to meet this requirement (it is > safe to assume that the applications are robust to this duplication). I am not sure I understand the transport implications of such duplication. I could imagine under some conditions it could introduce reordering or something that causes harm for TCP. > When an MR is completely disconnected from the > majority of the network it is intended to communicate, including its > HA, there is no requirement for it to be able to retain any > communications involving parties outside the mobile networks managed > by itself. Its great to have such non-requirements here as well. > 3.6. Req6 - Scalability > > > Req6 - An RO scheme MUST be simultaneously usable by ten thousand > nodes without overloading the ground network or routing system. This should be formulated more firmly. For instance, I would like to see an additional requirement that the solution MUST NOT inject updates to the global BGP routing table when planes move around. > 3.8. Req8 - Security > > > Req8 - IPsec MUST be usable over the RO scheme, and the data used to > make RO decisions MUST be authenticable, perhaps using some form of > IPsec. This requirement should be split up. The part about payload traffic being able to use IPsec should be generalized to any security mechanism. It might make sense to combine this with Req9. The part about securing the RO itself should be held separate. In addition, the requirement as it stands not sufficiently detailed to be useful. Start with the requirement that route optimization decisions must be taken by such and such nodes involved in the protocol, and that strong authentication is required for the signaling. Specify who is authorized make particular decisions. Specify what security infrastructure you are prepared to accept to allow all this to happen. Even so, there are other requirements that you may want to consider, such as what to do with securing path tests (but these may not be something that we completely secure). > Likewise, since the IPsec standards > seem to be the only widely-agreed upon framework for implementing > packet authentication and other security services, the use of IPsec > to authenticate or otherwise secure RO signaling and other data used > in the RO process is also desirable, but other reasonable > authentication mechanisms may be acceptable for RO signalling. As above. IPsec may be the right solution, but the text sounds like spreading security pixie dust to a hard problem. Specify the security requirements for your problem, not the solution. > This requirement was extrapolated from ICAO's TC-8 - "The approach > should be secure." Against what attacks? Making RO decisions by someone in the Internet? By someone on the path? By a legitimate participant but who does not "own" this particular prefix? By a compromised node? > For oceanic flight, ATS and AOS may > also benefit from the capability of nesting MRs between multiple > planes to provide a "reachback" to terrestrial groundstations rather > than relying solely on lower rate HF or satellite systems. In either > case, this mode of operation is beyond current strict requirements > and is merely desirable. This requirement makes sense to me, but it is also something that focuses on building ad hoc routing style networks. I would suggest that we have to keep this part of the problem space out of our effort if we are going to complete something. Lets look at the ad hoc routing aspect separately. I also do not necessarily believe that nested NEMOs are the right approach to doin such multi-hop manet routing. It seems preferrable that the MR deals with this by also acting as a, say, MANET router. > 4.4. Des4 - VMN Support > > At least LFNs and LMNs MUST be supported by a viable RO solution for > aeronautics, as these local nodes are within the ATS and AOS domains. > VMNs within the PIES domain are expected to be numerous, and it is > strongly desirable for them to be supported by the RO technique, but > not strictly required. What does "support" mean here -- presumably if Req9 is followed, it would be hard for any new technology to break nodes that employ VPNs, Mobile IPv6, HIP, or something like that. Or does "support" mean some additional feature that will be beneficial to the nodes? If so, please specify. Editorial: > (e.g. using Plain > Old Aircraft Communication Addressing and Reporting System (ACARS) > or ACARS over VHF Data Link (VDL) mode 2 ) Style: use "the old" instead of "plain old". Or some other choice of words... > Entertainment (IFE) systems may receive movie refreshes of data s/movie/television program/ ? I would expect that current news would be something of value to passengers. > When an MR is completely disconnected from the > majority of the network it is intended to communicate, including its > HA, there is no requirement for it to be able to retain any > communications involving parties outside the mobile networks managed > by itself. s/HA,/HA(s),/ > [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", > draft-ietf-nemo-terminology-06 (work in progress), > November 2006. > > [2] Ernst, T., "Network Mobility Support Goals and Requirements", > draft-ietf-nemo-requirements-06 (work in progress), > November 2006. > [7] Ng, C., "Network Mobility Route Optimization Problem > Statement", draft-ietf-nemo-ro-problem-statement-03 (work in > progress), September 2006. These are RFCs now. > [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. Make this a normative reference. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext
- [MEXT] review of draft-ietf-mext-aero-reqs Jari Arkko
- Re: [MEXT] review of draft-ietf-mext-aero-reqs Stuart W. Card
- Re: [MEXT] review of draft-ietf-mext-aero-reqs Jari Arkko
- Re: [MEXT] review of draft-ietf-mext-aero-reqs marcelo bagnulo braun