Dear Dale Worley,

Thank you for your comments.
Inline you will find replies to the raised issues and we are planning to 
incorporate related updates in the next version. 

Best,
Nils Mäurer

-----Ursprüngliche Nachricht-----
Von: Dale Worley via Datatracker <nore...@ietf.org> 
Gesendet: Freitag, 1. April 2022 04:51
An: gen-art@ietf.org
Cc: draft-ietf-raw-ldacs....@ietf.org; last-c...@ietf.org; r...@ietf.org
Betreff: Genart last call review of draft-ietf-raw-ldacs-10

Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-ietf-raw-ldacs-10
Reviewer:  Dale R. Worley
Review Date:  2022-03-31
IETF LC End Date:  2022-04-04
IESG Telechat date:  not known

Summary:

    This draft is basically ready for publication, but it seems to me
    to have open issues, depending on the intended scope of the
    document.

Issues:

There are a number of minor editorial issues listed below.  But the one issue 
that might be significant is the lack of detail about how LDACS is expected to 
utilize the IP infrastructure as defined by the IETF.  Strictly speaking, this 
document is an informational document about a particular data-link layer, and 
in that sense, layer 3 is out of scope, but what the IETF audience would be 
most informed by would be how the data-link layer integrates with IPv6 and 
existing IPv6 protocols.

- Reply: LDACS is a terrestrial access network technology for the upcoming Air 
Traffic Network/Internet Protocol Suite (ATN/IPS), which is a network 
technology that will route any Air Traffic Management (ATM) related information 
over IP. As such any access technology for the ATN/IPS operates directly with 
IP infrastructure and is in our opinion of strong interest to the IETF. LDASC 
offers an interface, the SNP, which will use IPv6 traffic as input, and adapt 
the input to LDACS specific packet format, and vice versa.

3.  Motivation and Use Cases

   It refers to the mostly
   proprietary exchange of data between the aircraft of the airline, its
   operation centers, and its service partners.

Not being in the airline industry, my initial reading of this was that aircraft 
had operation centers and service partners.  Perhaps this could be clarified 
for the naive as

   It refers to the mostly
   proprietary exchange of data between the aircraft of the airline and
   the airline's operation centers and service partners.

- Reply: Indeed, an aircraft does not have direct operation centers and service 
partners. The airline does. As such, we will use your suggestion as replacement.

3.1.  Voice Communications Today

   Voice links are used for Air/Ground (A/G) and Air/Air (A/A)
   communications. The communications equipment is either ground-based
   working in the High Frequency (HF) or VHF frequency band or
   satellite-based.

By comparison, 5.2.2 states that A/A communication is only considered as a 
possible extension for LDACS, which seemed surprising to read at that point.  
This could be clarified if 3.1 noted that LDACS is not currently planned to 
implement A/A communication, even for voice.

- Reply: It is foreseen that LDACS A/A will be implemented after the LDACS A/G 
rollout. As such, we will clarify this point in the document. 

5.2.  Application

   (sending Ground Based Augmentation System (GBAS) correction data)
 
Naively, this reads as "data to correct GBAS data".  Perhaps clearer as "Ground 
Based Augmentation System (GBAS) data to correct GNSS" or even just "GNSS 
correction data" as is used in 5.2.3.

- Reply: We will change it to "GNSS correction data".

7.  Characteristics

   Achieving the stringent continuity, availability, and integrity
   requirements defined in [DO350A] will require the specification of
   layer 3 and above mechanisms (e.g. reliable crossover at the IP
   layer). Fault management mechanisms are similarly undefined.

This limitation seems to be strictly correct, given that this document is only 
scoped to the data link layer.  But it would be useful to the reader to give an 
outline of how IP interacts with the data link layer.  In particular, are the 
packets sent over the link IPv6 packets (perhaps encoded in some special way)?  
What is the general IP addressing architecture of the LDACS sub-network (i.e. 
AS, GS, and AR)?
Similarly, what existing protocols (if any) are expected to reach the AS?  
These latter points are the ones that most directly intersect the IETF's 
business.

- Reply: As mentioned above, the SNP layer of LDACS directly interacts with 
IPv6 traffic. ATN/IPS packets are encoded in IPv6 and these are routed over 
LDACS from and to the aircraft. The final IP addressing structure in an LDACS 
subnet still needs to be defined, however, for aircraft, the addressing is set 
as follows: ICAO prefix 16bit, Aircraft Type (Operator based) 4 bit, Operator 
Code 16 bit, Aircraft ID 24bit, Application Type 4bit. The current layout is 
considered to consist of the five network segments: Air Core Net, Air 
Management Net, Ground Core Net, Ground Management Net, Ground Net.
Any protocols that the ATN/IPS defines as mandatory will reach the aircraft, 
however we think that listing these here in the LDACS draft is out of its 
actual scope.
We will update the draft with the provided updates above. 

7.3.  LDACS Protocol Stack

    The last entity resides within the sub-network layer: the
    Sub-Network Protocol (SNP). 

Given the context of this sentence, "the last entity" could refer to either 
functional block five, or to item (4) in the immediately preceding list (the 
LME).  This would be less ambiguous as "The fifth block ...".

- Reply: "The last entity" was supposed to refer to the last functional entity 
in the LDACS protocol stack, hence the last one, which was not mentioned yet. 
We will clarify this accordingly.

   The LDACS network is externally
   connected to voice units, radio control units, and the ATN network
   layer.

How does this mesh with the architecture shown in Figure 1 of 7.1, which shows 
only the connection of LDACS to ATN?

- Reply: We agree, that this sentence is poorly formulated. Figure 1 depicts 
the user-data (or payload) view, hence user-data travels from ATN over ATN/IPS 
to the A/G router, to the AR and then to the GS, is sent via LDACS to the AS, 
and then further used as ATN/IPS traffic (the reverse direction applies 
similarly in reverse order). As such, the control plane for voice or radio 
units is simply not depicted in Figure 1. We will streamline this to give the 
reader a better understanding to what we are referring to.

--

Figure 2 doesn't show the positioning of the VI functional block.

- Reply: That is true. We will update it accordingly.

8.2.  Layer 1 and 2

The figures in this section have very little information for a diagram of a 
frame structure.  E.g. the length of an SF is specified (240ms =
2000 symbols), but the lengths of MF, BCCH, and RACH are not specified.  
Similarly, the lengths of the divisions of the MF aren't specified.  The layout 
and size of the transmission time slots aren't discussed.

   FL and RL boundaries are aligned in time (from the GS perspective) 

Given that a cell can be as large as 200 nautical miles, which is 1235 
microseconds at light-speed, and a symbol is 120 microseconds, while the FL and 
RL frame structures are synchronized at the GS, they can be desynchronized by 
~20 symbols at the AS.  This seems to be handled by propagation guard times but 
it would be useful to describe the guard time placements in the frame 
structures.

- Reply: We will update the frame structure to incorporate more information and 
give detailed descriptions of the guard time placements within it.

8.3.  Beyond Layer 2

   This means proliferating the number of terrestrial ground
   stations. However, the scarcity of aeronautical spectrum for data
   link communication (in the case of LDACS: tens of MHz in the
   L-band) and the long range (in the case of LDACS: up to 200
   nautical miles) make this quite hard.

Naively, the available bandwidth for the LDACS system as a whole in a 
geographical region should scale with the number of cells.  The above statement 
suggests that is not true in LDACS, and it would be useful to explain why.

- Reply: What we are saying here are three things: 1. aeronautical spectrum for 
data  link communications is very scarce 2. An increase in the amount of ground 
stations also increases the individual bandwidth for aircraft in the cell, as 
fewer aircraft have to share that specific spectrum 3. However, to cover 
worldwide terrestrial ATM via LDACS is also a question of cost and the possible 
reuse of spectrum which makes it not always possible to shrink cell sizes. We 
will update this statement to make it more clear.

9.5.1.  Entities

The document seems to be using "LDACS access network" in 9.5.1 and "LDACS 
Sub-Network" in Figure 1 of 7.1 to mean the same thing.
Neither term is defined in 2.  Can these be unified into one term?
Would it help to insert it in the glossary?

- We will insert it in the glossary and only use one term from here on out.

[END]



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to