Re: [manet] Fwd: [Raw] Proposed RAW charter

Rex Buddenberg <> Tue, 14 January 2020 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35F6C12001B for <>; Mon, 13 Jan 2020 18:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCK4ls7OhC2V for <>; Mon, 13 Jan 2020 18:08:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 551BE120048 for <>; Mon, 13 Jan 2020 18:08:57 -0800 (PST)
Received: by with SMTP id b137so5626550pga.6 for <>; Mon, 13 Jan 2020 18:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=3w7Y13z/J49KZ1N+KZeIbE/GJIIosh0fGaO52RwP48g=; b=kUAU737cj/KCw6zCevwGj9L484z5HPNYWTro+FElEozdKxPSJZeC2bPoV8SLkEUYJB wJTwpZEqq3Eo+SZLIHOJmJKccIdpHNMKZluHqTZVEI1qKpfIoKb/+ewRN+vddGC3S+TX PhZSVPGlYsqMnkHvNw4gzKmgZYwJAxISpOVHr4iigeBmnAdSZ9VHj9HsvHJWLZ5D24KS Ebu4sVa0cuVQAGKzl2fAGA3P4aGjqQidkz6v7Gejk+/YaxgEqWLbqYtHEBkMomRGX9vq 1msBuj1BPuJGB2xXNPvxpvFbVDPwLfd0MUiEj4xcy8pIav+mQsD+rr6y6A2YXfZeLTSl RiGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=3w7Y13z/J49KZ1N+KZeIbE/GJIIosh0fGaO52RwP48g=; b=EsucTf1rcGRSgmTuQRMfBx8n63lH1M/JLhIfBRAmUnSPAbGG/h8ycFoEf+Y2Or8bQj 5kbgRIc4f78LmgSOcmvuhJhCG13GzKLEzobAjJQUquf6mBnZTCJiR6vbsBbKby/BGb8T hAUnHYxzSJ8t5FQgd0mShzL9DTBsRB2+RkBFx207KUFctt7d/DrNJd5lKKTZa7FrtZiQ HwYwsyNaUUGAxRkLPuI0D/Hgx7fMf1NtDDYTxPH1x1UaA3xKrrCVtLwe7SQNGq5tPbhq GDZ//rbq6RBw/4OnGZeflnm8rWeOy3QDmfFKz9oCBO0gLiuHc88zxxPgtYssyV34B5El 1DKQ==
X-Gm-Message-State: APjAAAU2CkQbqS6qRsrOJokZF/Yh1oNE9Z/NfE+zES9ja97nRCcacSxi CTg5j08k3PNtoUxewBxxtWY=
X-Google-Smtp-Source: APXvYqxF2PvhklkSNKqzl/L48HrfVrWUBGiO2wmtQc69zp7dMpRwQxtd/ATGBeQ6M6HCUrxR025EtA==
X-Received: by 2002:a63:1666:: with SMTP id 38mr25019307pgw.325.1578967736620; Mon, 13 Jan 2020 18:08:56 -0800 (PST)
Received: from localhost.localdomain ( []) by with ESMTPSA id q11sm15595402pff.111.2020. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Jan 2020 18:08:55 -0800 (PST)
Message-ID: <>
From: Rex Buddenberg <>
To: Alvaro Retana <>, MANET IETF <>
Date: Mon, 13 Jan 2020 18:08:54 -0800
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution (
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [manet] Fwd: [Raw] Proposed RAW charter
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jan 2020 02:09:00 -0000

Comments in line.

On Mon, 2020-01-13 at 15:23 -0800, Alvaro Retana wrote:
> FYI…
> Bellow is a proposed charter for RAW.  As you can see, it
> specifically calls DLEP and the manet WG out.
> Please take a look and, as possible, contribute to the definition of
> the charter and the work to be done.
> Thanks!
> Alvaro.
> On January 13, 2020 at 4:14:59 PM, BRUNGARD, DEBORAH A (
> m) wrote:
> > Hi RAW,
> >  
> > Happy New Year!
> >  
> > As promised, here’s a proposed charter. Please send comments. I’ll
> > be submitting it to the IESG for the first step (internal review)
> > by the end of the week.
> >  
> > Note, while the BoF had the most support for doing only use cases
> > and requirements, I’ve included here also a gap analysis and an
> > architecture/framework document. I think the gap analysis will be
> > the most critical. The architecture/framework is intended not to be
> > the typical comprehensive protocol architecture, but only
> > architectural aspects of what is needed to enable deployment and
> > usage in a wireless network.
> >  
> > Looking forward to your comments-
> > Deborah
> > (your supporting AD)
> >  
> > --
> >  
> > Reliable and Available Wireless (RAW) provides for high reliability
> > and availability for IP connectivity over a wireless medium... 

I'd imagine that most internetworks would have wireless segments in
them but would not be exclusively wireless.  The way this is stated,
you imply all-wireless.  We have two topologies to deal with:
  - the 'conventional' one with the wireless at the edge (last router-
end system LAN problem).  The rest of the internetwork is wired.
  - the less conventional one where there is a radio-WAN (meaning
router-router) wireless segment in the interior or the internetwork.
(contention MACs don't work here.  

> > The wireless medium presents significant challenges to achieve
> > deterministic properties such as low packet error rate, bounded
> > consecutive losses, and bounded latency. 

While this is true, these are qos issues, not reliability/availability
ones. What are we after? I think there is a case for high availability
engineering, but wrapping yourself up on qos issues is not the way to
get at it.

> > RAW extends the DetNet Working Group concepts to provide for high
> > reliability and availability for an IP network utilizing scheduled
> > wireless segments and other media, e.g., frequency/time-sharing
> > physical media resources with stochastic traffic: IEEE Std.
> > 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable 
> > low latency communications (URLLC), IEEE 802.11ax/be, and L-band
> > Digital Aeronautical Communications System (LDACS). Similar to
> > DetNet, RAW will stay abstract to the radio layers underneath,
> > addressing the Layer 3 aspects in support of applications requiring
> > high reliability and availability.

This is a catalog of prospective solutions, not a statement of
requirements. Or, restated, the prospective solutions ... but to what

> >  
> > While DetNet solutions apply to both wireless and wired, there has
> > been recent industry interest for wireless applications which were
> > not initially included in the DetNet use cases. One critical
> > application is Aeronautical Data Communications. The Aeronautical
> > standards work on a physical layer and data link layer for data
> > communications is reaching maturity and there is significant
> > interest in developing an IP connectivity solution.

I think there is an automotive application that is as compelling. In
both cases, emergency vehicles should be highlighted in the use cases
and requirements statements as they tend to represent the 'tall pole in
the tent'.  Meet the requirements for an instrumented ambulance and
you'll exceed most others.  

In both cases a mature view of the topology is necessary: you're using
the wireless to reach to a LAN inside the vehicle.  That is, the
vehicle is not an end system but a transport of one or more network
segments.  Therefore the wireless segment of concern is a router-router 
segment of an internetwork -- in the interior, not at the edge.  

> >  
> > In the interests of providing timely solutions for these newly
> > identified industry applications, RAW’s focus will be on
> > identifying use cases and requirements for these new applications.
> > RAW will solicit input on deployment plans, requirements, and
> > operational practices (including security and privacy aspects) for
> > these newer industrial applications. RAW’s primary focus is on
> > identifying areas where the DetNet adaptation to wireless networks
> > requires additional supporting mechanisms. The RAW Working Group
> > will also examine the applicability of other existing IETF work,
> > e.g..., DLEP.  The RAW Working Group will provide input to the
> > DetNet Working Group, MANET Working Group, and other IETF Working
> > Groups, and cooperate in reviewing solutions to RAW’s identified
> > deployment problems. RAW is not chartered to work on a solution, if
> > solution work is needed in addition to the DetNet solution work or
> > other existing solution work in the IETF, it will be coordinated on
> > where the work will be done.

I'm confused.  In the first sentence the WG is to provide timely
solutions.  But the last sentence says something a bit different. ??

In the military's world, we have two flavors of such documents; Mil
Standards and Mil Handbooks. Engineering coaching and best practices
generally are found in the latter.  

> >  
> > The RAW Working Group is planned to be a short timeframe (12-18
> > months) Working Group to quickly address these newer industry
> > applications. The initial milestones will be comprised of
> > Informational documents. The documents may exist individually or on
> > a git repository. The use case document may consist of one or more
> > documents to allow users/operators the opportunity to provide
> > comprehensive deployment plans for these new (to IETF)
> > technologies. The group will closely coordinate with the DetNet and
> > MANET Working Groups. The work produced by this group may be of
> > interest to other SDOs, 3GPP, IEEE, and the Aeronautical industry.
> > No formal co-ordination is anticipated with these groups at this
> > time.

> > Milestones
> > Draft for “Use Cases” adopted by WG
> > Draft for “Problem Statement and Requirements” adopted by WG
> > Draft for “Architectural/Framework aspects to enable deployment and
> > usage in a wireless network” adopted by WG
> > Draft for “Evaluation of Existing IETF Tools and Gap Analysis”
> > adopted by WG
> > Draft for “Use Cases” submit for publication
> > Draft for “Problem Statement and Requirements” submit for
> > publication
> > Draft for “Architectural/Framework aspects to enable deployment and
> > usage in a wireless network” submit for publication
> > Draft for “Evaluation of Existing IETF Tools and Gap Analysis”
> > submit for publication
> >  

I don't see below where we're supposed to recite the definitions and
principles that are central to high availability internetworks.  You
need these.....

Definition. Availability is defined as up-time/total-time.  With a bit of algebra that can be restated as (total-time - down-time)/total-time. It's usually easier to identify tolerable down-time in the analysis. 
   In my experience the hardest part of the problem is to get the sponsor to state the Ao requirements. I've seen several programs of this ilk that made no availability requirement statement at all. 

Principles.  There are three principles of high availability engineering:
 - elimination of single points of failure (e.g. by provisioning of alternate network segments)
 - reliable crossover from primary to backup (IP does this by design)
 - prompt notification of failures as they occur (part of the management function, fault management)


> >  
> > -- 
> > Raw mailing list 
> > 
> > 
> _______________________________________________
> manet mailing list