Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Meiling Chen <chenmeiling@chinamobile.com> Fri, 25 February 2022 03:05 UTC

Return-Path: <chenmeiling@chinamobile.com>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3F43A1101 for <etosat@ietfa.amsl.com>; Thu, 24 Feb 2022 19:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqeG3j61QqBy for <etosat@ietfa.amsl.com>; Thu, 24 Feb 2022 19:05:05 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58FEF3A10FC for <etosat@ietf.org>; Thu, 24 Feb 2022 19:05:03 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.81]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee26218475e7f2-f77eb; Fri, 25 Feb 2022 11:05:02 +0800 (CST)
X-RM-TRANSID: 2ee26218475e7f2-f77eb
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[10.2.51.26]) by rmsmtp-syy-appsvrnew01-12030 (RichMail) with SMTP id 2efe62184685083-d0a21; Fri, 25 Feb 2022 11:01:27 +0800 (CST)
X-RM-TRANSID: 2efe62184685083-d0a21
Date: Fri, 25 Feb 2022 11:05:12 +0800
From: Meiling Chen <chenmeiling@chinamobile.com>
To: Lin Han <lin.han@futurewei.com>, Marie-Jose Montpetit <marie@mjmontpetit.com>, Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>, Arashmid Akhavain <arashmid.akhavain@gmail.com>
Cc: EToSat <etosat@ietf.org>, "Tomaso.deCola@dlr.de" <tomaso.decola@dlr.de>, "ray@oneunified.net" <ray@oneunified.net>
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com>, <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net>, <85aa1a9d30c745c08598384bb68bdcf9@dlr.de>, <CAL0D2oRBmEF0J8=3OJ0UNi7TfLkKJudvhVVsGg9wAEw4H-V8RQ@mail.gmail.com>, <CAC4j5ET9988rpnq0GrrGspY9HEnc+YoLRP0-1DdQmdTSPsjZ3w@mail.gmail.com>, <BY5PR13MB314462E940D269AD6CBB74CAE93C9@BY5PR13MB3144.namprd13.prod.outlook.com>, <CAPjWiCS-eY9hsyxb+6iEOr-OK9fK_8Oqd7c44GvrkUwiAYDhmg@mail.gmail.com>, <BY5PR13MB31448E1CB932962E5E539302E93D9@BY5PR13MB3144.namprd13.prod.outlook.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.115[cn]
Mime-Version: 1.0
Message-ID: <2022022511051209402716@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart315063888146_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/RMXtNSnlkTsOsRCX61dvUB22jbk>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2022 03:05:10 -0000

Hi all,
Indeed, there are still many issues to be discussed in satellite networks and the issues involved will also span multiple working groups.
No matter which layer of the protocol, the existing protocols may have some problems that are not applicable to satellite networks.
Although 3GPP is studying how to integrate satellite networks with terrestrial networks, there is no definite architecture yet.
The technology and background related to satellite networks are very professional. Why not consider setting up a special working group to do research or standardization.

Best,
Meiling

From: Lin Han
Date: 2022-02-24 10:28
To: Marie-Jose Montpetit; Nicolas Kuhn; Arashmid Akhavain
CC: etosat@ietf.org; Tomaso.deCola@dlr.de; ray@oneunified.net
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
Hi, Marie,
I have requested session in RTGWG, INTAREA. Probably in DMM as well.
Since there is no dedicated WG for the satellite networking work in IETF now, the potential solutions may be crossing different WGs.
Welcome all who are interested in this area for future Internet to attend and comment.
 
Thanks
 
Lin
 
 
From: Marie-Jose Montpetit <marie@mjmontpetit.com> 
Sent: Wednesday, February 23, 2022 5:42 PM
To: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>; Lin Han <lin.han@futurewei.com>; Arashmid Akhavain <arashmid.akhavain@gmail.com>
Cc: etosat@ietf.org; Tomaso.deCola@dlr.de; ray@oneunified.net
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
 
Where do you intend to present at 113?
 
Marie-José Montpetit, Ph.D.
marie@mjmontpetit.com
 
 

From: Lin Han <lin.han@futurewei.com>
Reply: Lin Han <lin.han@futurewei.com>
Date: February 23, 2022 at 5:15:16 PM
To: Arashmid Akhavain <arashmid.akhavain@gmail.com>, Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
Cc: etosat@ietf.org <etosat@ietf.org>, Tomaso.deCola@dlr.de <tomaso.decola@dlr.de>, ray@oneunified.net <ray@oneunified.net>
Subject:  Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt 


Good question. Actually this has been studied by 3gpp. 3gpp has proposed the Satellite-based NG-RAN architectures in TR38.821. In this architecture, satellite network is an infrastructure for 5G. In its proposed “Regenerative payload” mode, satellite network (with ISL) should provide the IP connectivity for wireless access and NTN integration. Different SP is able to use satellite as wireless access network. From this expectation, satellite network will be access and backhaul network for wireless, the standardized protocol/methods are expected.
I will have a slide in the next IETF meeting to explain more details about the problems.
 
Regards
 
Lin
 
From: Arashmid Akhavain <arashmid.akhavain@gmail.com> 
Sent: Wednesday, February 23, 2022 12:36 PM
To: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
Cc: Tomaso.deCola@dlr.de; etosat@ietf.org; ray@oneunified.net
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
 
That could be another alternative. 
The question that I have been struggling with is whether and how satellite networks can benefit from standardisations. These networks are proprietary (at least for the time being). It is difficult to imagine satellites in a multi-vendor ecosystem. 
 
That's why I asked what the authors of this draft intended to do.
 
Arashmid
 
On Wed, Feb 23, 2022 at 3:12 PM Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com> wrote:
Thanks Tomaso for the interesting pointer. 
 
This kind of work is very useful when it comes to design routing strategies for mega constellation systems. 
If there are any public outputs of the SDN approach, I would be very interested in having a look. 
 
What I think would be also very interesting to discuss in terms of IETF perspective is to assess whether existing routing mechanisms (OSPF, SegmentRouting) require specific changes for the use case. 
 
Nico
 
On Wed, Feb 23, 2022 at 10:33 AM <Tomaso.deCola@dlr.de> wrote:
If of any interest or support to the discussion on routing for LEO, colleagues of mine at DLR published the following paper last year:
 
Roth, M, Brandt, H, Bischl, H. Implementation of a geographical routing scheme for low Earth orbiting satellite constellations using intersatellite links. Int J Satell Commun Network. 2021; 39: 92– 107. https://doi.org/10.1002/sat.1361 
 
Then we are now working on SDN in space as enabler for new concepts of routing and network management, as part of an ESA-funded project.
 
Best Regards,
 
Tomaso de Cola
 
 
———————————————————————— 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola@dlr.de 
http://www.dlr.de/kn/institut/abteilungen/san 
 
 
 
From: EToSat <etosat-bounces@ietf.org> On Behalf Of Raymond Burkholder
Sent: Mittwoch, 23. Februar 2022 04:07
To: etosat@ietf.org
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
 
On 2022-02-22 1:27 p.m., Arashmid Akhavain wrote:
I agree that existing IP routing protocols can face convergence issues when it comes to satellite networks. IP and existing routing protocols rely on hierarchy to minimise the impact of link events. Establishing hierarchy in satellite networks can be very complex due to various movements especially when it comes to massive constellations.
 
In polar constellations, the movement at the poles, and the seam plane will be problematic for existing routing protocols. The issue of course gets exacerbated in the Walker Delta constellation as the seam effect exists between every other orbit.
 
A new method of routing might be required to address this issue. What are your plans w.r.t to this draft? Have you discussed some of these issues with any of the working groups?
Using standard routing protocols are problematic as they are reactive.  And due to inter-satellite delays, can take time to re-converge.  I was working with a company to come up with an SDN solution where we used TLE (Two Line Elements) to compute satellite nearness and then pre-populate neighbor entries for installation at pre-arranged times.

In addition, to do this properly, these neighbor entries and routing table entries need to be populated based upon distributed path computation capabilities (due to the fact that the same ground stations are not always in view, and paths need to be adjusted as necessary).
 
Best regards,
Arashmid
 
 
_______________________________________________EToSat mailing listEToSat@ietf.orghttps://www.ietf.org/mailman/listinfo/etosat
 
_______________________________________________
EToSat mailing list
EToSat@ietf.org
https://www.ietf.org/mailman/listinfo/etosat
_______________________________________________
EToSat mailing list
EToSat@ietf.org
https://www.ietf.org/mailman/listinfo/etosat
_______________________________________________ 
EToSat mailing list 
EToSat@ietf.org 
https://www.ietf.org/mailman/listinfo/etosat