Geographic Location for Media over QUIC Relays
draft-altanai-moq-relay-geocode-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Altanai Bisht , Tim Evens | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-altanai-moq-relay-geocode-02
moq A. Bisht
Internet-Draft Cisco Meraki
Intended status: Standards Track T. Evens
Expires: 5 February 2027 Cisco
4 August 2026
Geographic Location for Media over QUIC Relays
draft-altanai-moq-relay-geocode-02
Abstract
This document defines a mechanism for Media over QUIC (MoQ) relays to
advertise their geographic location (geocode) and related path
metrics. Some clients require their media data to remain locally or
geo-fenced within specific jurisdictions for privacy and security
compliance (e.g., GDPR, HIPAA, or sector-specific regulations). This
mechanism enables service providers to track the geographic path of
media packets through the relay mesh and to enforce geo-fencing
policies. It supports Geo-Distributed Orchestration and Routing
(GDOR), data residency compliance, latency optimization, and relay
selection. The specification includes optional IATA airport codes as
human-readable geographic identifiers for major relay locations.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://datatracker.ietf.org/doc/draft-altanai-moq-relay-geocode/.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-altanai-moq-relay-geocode/.
Discussion of this document takes place on the moq Working Group
mailing list (mailto:moq@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
Source for this draft and an issue tracker can be found at
https://github.com/altanai/draft-altanai-moq-relay-geocode.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bisht & Evens Expires 5 February 2027 [Page 1]
Internet-Draft MoQ Relay Geocode August 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 5 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Relay Selection by Proximity . . . . . . . . . . . . . . 5
3.2. Geo-Distributed Orchestration (GDOR) . . . . . . . . . . 5
3.3. Path and Vicinity Awareness . . . . . . . . . . . . . . . 5
3.4. Metrics Integration . . . . . . . . . . . . . . . . . . . 6
4. Geocode Representation . . . . . . . . . . . . . . . . . . . 6
4.1. Suggested Format: WGS84 Coordinates . . . . . . . . . . . 6
4.2. Suggested: IATA Code . . . . . . . . . . . . . . . . . . 6
5. Integration with MoQ . . . . . . . . . . . . . . . . . . . . 6
5.1. Option 1: Path Trace via MOQT Extension Headers
(RECOMMENDED) . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Option 2: Geocode Advertisement via MOQT Messages and
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Option 3: Catalog Integration . . . . . . . . . . . . . . 8
5.4. Option 4: Metrics Integration . . . . . . . . . . . . . . 8
5.5. Option 5: Discovery (Well-Known URI or Setup Option) . . 8
6. Vicinity and Path Computation . . . . . . . . . . . . . . . . 8
Bisht & Evens Expires 5 February 2027 [Page 2]
Internet-Draft MoQ Relay Geocode August 2026
6.1. Great-Circle Distance . . . . . . . . . . . . . . . . . . 8
6.2. Path Metrics . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Vicinity Semantics . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. Misuse . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example Topology (Informative) . . . . . . . . . . . 10
Appendix B. IATA Code Reference (Informative) . . . . . . . . . 11
Appendix C. Relay Advertisement Format (Informative) . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Media over QUIC Transport (MOQT) [MoQTransport] uses a relay-based
architecture where publishers push media to relays and subscribers
pull from relays. Relays can be chained for CDN-like distribution,
forming a mesh of interconnected nodes. In such topologies, as
illustrated by deployments with multiple relays (e.g., relays A, B,
C, D) connecting Home/Enterprise clients to a Service Media backend,
the following questions arise:
* *Where* is each relay located geographically?
* *How close* are relays to each other and to clients?
* *Which path* through the relay mesh minimizes latency or satisfies
policy?
Today, MoQ provides no standard way for relays to advertise
geographic position. Clients and orchestration systems rely on
external mechanisms (e.g., IP geolocation feeds [RFC8805], manual
configuration) that are often imprecise, inconsistent, or
unavailable. This document specifies a lightweight, protocol-aligned
mechanism for relays to advertise geocode and related metrics,
enabling:
1. *Vicinity and path computation*: Determining physical proximity
and logical paths between relays.
2. *GDOR (Geo-Distributed Orchestration/Routing)*: Making routing
and placement decisions based on geography (e.g., route through
EU relays for GDPR, avoid certain jurisdictions).
Bisht & Evens Expires 5 February 2027 [Page 3]
Internet-Draft MoQ Relay Geocode August 2026
3. *Latency optimization*: Selecting relays with lower RTT or
propagation time (PT) to the client or to upstream relays.
4. *Data residency and compliance*: Ensuring media flows stay within
required geographic boundaries. Clients often require their data
to be locally or geo-fenced for privacy and security compliance
(e.g., GDPR, HIPAA).
5. *Path tracking*: Enabling service providers to track the
geographic path of media packets through the relay mesh for
compliance audits and geo-fencing enforcement.
1.1. Design Goals
* *Path trace in-band (primary)*: Use MOQT extension headers on
objects for path tracing as the RECOMMENDED integration. Each
relay/proxy appends device name and direction; clients can verify
the geographic path from received objects.
* *Protocol alignment*: Use existing MOQT messages (PUBLISH,
SUBSCRIBE) and streams for geocode advertisement, avoiding new
message formats. Relays do not need to invent proprietary
messaging for cross-vendor use cases.
* *Minimal protocol impact*: Reuse existing MoQ catalog, metrics, or
discovery mechanisms where possible.
* *Interoperability*: Use standard geographic representations
(WGS84, GeoJSON) and widely recognized identifiers (IATA codes).
* *Extensibility*: Allow optional altitude, region codes, and path
metrics (RTT, PT) without mandating them.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
*Geocode*: A representation of geographic position, typically
latitude and longitude (WGS84), optionally with altitude.
*Relay Vicinity*: The geographic proximity of one relay to another or
to a client, expressed as distance or as a qualitative relationship
(e.g., same region, same metro).
Bisht & Evens Expires 5 February 2027 [Page 4]
Internet-Draft MoQ Relay Geocode August 2026
*Relay Path*: A sequence of relays through which media flows from
publisher to subscriber, or the logical/geographic route between
relays.
*GDOR (Geo-Distributed Orchestration/Routing)*: Routing and
orchestration decisions that consider geographic location, including
data residency, latency optimization, and jurisdictional compliance.
*IATA Code*: A three-letter code assigned by the International Air
Transport Association to identify airports and major metropolitan
areas (e.g., JFK, LHR, FRA). Used here as an optional human-readable
geographic identifier for relay locations.
3. Use Cases
3.1. Relay Selection by Proximity
A subscriber in New York (NY) may have multiple relays available
(e.g., A, B, C, D). With geocode and RTT/PT metrics, the client or
an orchestration layer can select the relay that minimizes latency or
satisfies geographic constraints.
3.2. Geo-Distributed Orchestration (GDOR)
Some clients require their media data to remain locally or geo-fenced
within specific jurisdictions for privacy and security compliance
(e.g., GDPR, HIPAA, or sector-specific regulations). An operator may
require that:
* EU subscriber traffic flows only through EU relays.
* Media for a given jurisdiction is processed within that
jurisdiction.
* Path selection avoids certain regions for policy or cost reasons.
Geocode enables GDOR by allowing relays to advertise their
jurisdiction (e.g., via country/region codes) and by allowing path
computation to respect geographic boundaries. Service providers can
use relay geocode and the advertised neighbor topology to *track the
geographic path* of media packets as they traverse the MoQ relay
mesh, supporting compliance audits and geo-fencing enforcement.
3.3. Path and Vicinity Awareness
In a relay mesh (e.g., A↔B↔C↔D), knowing the geocode of each relay
allows:
Bisht & Evens Expires 5 February 2027 [Page 5]
Internet-Draft MoQ Relay Geocode August 2026
* *Vicinity*: Computing great-circle distance or approximate
propagation delay between relays.
* *Path*: Understanding the geographic route (e.g., NY → Relay D →
Relay A → SVC) and optimizing it.
3.4. Metrics Integration
Deployments commonly measure *RTT to Relay* and *PT (Propagation
Time) to Relay* as key metrics. Geocode complements these by
providing a stable, policy-relevant attribute (location) that does
not change with network conditions, while RTT/PT provide dynamic
performance signals.
4. Geocode Representation
This section is informative. The following formats are suggested for
representing relay geocode; implementations may use alternative
representations.
4.1. Suggested Format: WGS84 Coordinates
Relay geocode may be represented as WGS84 coordinates (as used in
GeoJSON [RFC7946]):
* *latitude*: Decimal degrees, -90 to 90.
* *longitude*: Decimal degrees, -180 to 180.
* *altitude* (optional): Meters above WGS84 ellipsoid.
Example (JSON):
json { "latitude": 40.6413, "longitude": -73.7781, "altitude": 4 }
4.2. Suggested: IATA Code
An IATA airport code may be included as a human-readable geographic
identifier (e.g., JFK for New York, LHR for London). It is advisory
only and may correspond to the nearest major airport or metro area
where the relay is located; precise routing may use latitude/
longitude when geographic accuracy is required.
5. Integration with MoQ
This document proposes several integration options for geocode
advertisement and path tracing.
Bisht & Evens Expires 5 February 2027 [Page 6]
Internet-Draft MoQ Relay Geocode August 2026
5.1. Option 1: Path Trace via MOQT Extension Headers (RECOMMENDED)
To enable clients to verify the geographic path of media objects as
they traverse relays and proxies, relays and proxies MAY append a
path-trace entry to a MOQT object extension header as objects are
forwarded. Path tracing uses the extension header mechanism
described in [MoQTransport] (Section 10.2.1.2).
Each path-trace entry in the extension header SHOULD include:
* *device*: Name or identifier of the relay or proxy (e.g.,
relay_id, hostname, or a compact label such as relay-D).
* *direction*: The direction of traversal at this device, e.g.,
ingress (object received from upstream toward publisher) or egress
(object sent toward downstream subscriber). Alternative encodings
such as upstream/downstream or in/out may be used.
Additional fields such as iata_code, country, or subdivision MAY be
included for compliance and geo-fencing verification.
Example path-trace entry (informative):
json { "device": "relay-D", "direction": "egress", "iata_code": "JFK"
}
Clients that receive objects can inspect the extension header to
reconstruct the relay path (e.g., relay-D (JFK) egress → relay-A
(FRA) ingress → relay-A egress) for compliance audits or geo-fencing
enforcement.
This is the RECOMMENDED for path tracing as it travels in-band with
media and enables clients to verify the geographic path directly from
received objects.
5.2. Option 2: Geocode Advertisement via MOQT Messages and Streams
Relays MAY advertise geocode using standard MOQT messages and
streams:
* *PUBLISH*: A relay publishes its geocode advertisement as a track
(e.g., under a reserved namespace such as moq://relay-
geocode.example/v1/<relay_id>).
* *SUBSCRIBE*: Other relays, clients, or orchestration systems
SUBSCRIBE to geocode tracks to discover relay locations and
neighbor topology.
Bisht & Evens Expires 5 February 2027 [Page 7]
Internet-Draft MoQ Relay Geocode August 2026
* *Streams*: Geocode data is carried in MOQT objects over QUIC
streams, using the JSON schema defined in the related document
(Appendix C) as the object payload.
This approach reuses the same protocol that relays already use for
media distribution. No new message types or wire formats are
required.
5.3. Option 3: Catalog Integration
A relay MAY include geocode in catalog metadata for namespaces or
tracks it serves. Clients that discover tracks via the catalog can
use geocode for relay selection or policy checks.
5.4. Option 4: Metrics Integration
Geocode MAY be part of metrics exposed per [MoQMetrics] for relay
selection and monitoring. Resources (e.g., relays) can include
geocode as attributes in the metrics data model.
5.5. Option 5: Discovery (Well-Known URI or Setup Option)
A relay MAY serve geocode at a well-known path (e.g., /.well-known/
moq-relay-geocode) or via a Setup Option in SETUP, for deployments
that prefer HTTP-based or session-level discovery. Deployments MAY
also advertise geocode as provisioning-domain data per [RFC8801].
The reserved namespace, extension header type, and exact encoding for
the path trace are left to a companion specification or a future
revision of [MoQTransport].
6. Vicinity and Path Computation
6.1. Great-Circle Distance
Given two relays with geocode (lat1, lon1) and (lat2, lon2), the
approximate great-circle distance in kilometers can be computed using
the Haversine formula or an equivalent. This provides a stable
measure of physical proximity independent of network topology.
6.2. Path Metrics
When relays advertise neighbor topology (e.g., neighbors with rtt_ms
and pt_ms per the schema in Appendix C), a client or orchestration
system can:
1. *Build a relay graph*: Nodes = relays, edges = neighbor
relationships with RTT/PT.
Bisht & Evens Expires 5 February 2027 [Page 8]
Internet-Draft MoQ Relay Geocode August 2026
2. *Compute paths*: Shortest path by RTT, by PT, or by geographic
distance.
3. *Apply GDOR constraints*: Filter paths to those that stay within
required jurisdictions (using country and subdivision codes as in
[RFC9388]).
6.3. Vicinity Semantics
* *Same metro*: Relays with the same iata_code or within ~50 km.
* *Same region*: Relays with the same subdivision or country.
* *Cross-border*: Path crosses country boundaries; may trigger
compliance checks.
7. Security Considerations
7.1. Privacy
* Geocode reveals relay location. Operators who wish to hide exact
location MAY advertise only country and subdivision, or a coarse-
grained geocode (e.g., rounded to 0.1°).
* IATA codes are less precise than coordinates and may be preferred
when exact location must not be disclosed.
7.2. Integrity
* Geocode advertisements SHOULD be integrity-protected (e.g., over
TLS as with MoQ) and, when used for compliance, SHOULD be
verifiable (e.g., signed by a trusted authority).
7.3. Misuse
* Adversaries could advertise false geocode to attract traffic or
evade geographic restrictions. Relays SHOULD be authenticated;
geocode from untrusted sources SHOULD be validated or ignored.
8. IANA Considerations
This document does not require IANA actions. If a well-known URI or
a MoQ parameter type is registered in the future, the appropriate
IANA registry would be updated.
9. References
9.1. Normative References
Bisht & Evens Expires 5 February 2027 [Page 9]
Internet-Draft MoQ Relay Geocode August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7946] Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S.,
and T. Schaub, "The GeoJSON Format", RFC 7946,
DOI 10.17487/RFC7946, August 2016,
<https://www.rfc-editor.org/rfc/rfc7946>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
[MoQMetrics]
Jennings, C., "Metrics over MOQT", Work in Progress,
Internet-Draft, draft-jennings-moq-metrics-02, 2025,
<https://datatracker.ietf.org/doc/draft-jennings-moq-
metrics/>.
[MoQTransport]
IETF MOQ WG, "Media over QUIC Transport", Work in
Progress, Internet-Draft, draft-ietf-moq-transport-17,
2026, <https://datatracker.ietf.org/doc/draft-ietf-moq-
transport/>.
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/rfc/rfc8801>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/rfc/rfc8805>.
[RFC9388] Sopher, N. and S. Mishra, "Content Delivery Network
Interconnection (CDNI) Footprint Types: Country
Subdivision Code and Footprint Union", RFC 9388,
DOI 10.17487/RFC9388, July 2023,
<https://www.rfc-editor.org/rfc/rfc9388>.
Appendix A. Example Topology (Informative)
The following example illustrates a typical relay mesh topology:
Bisht & Evens Expires 5 February 2027 [Page 10]
Internet-Draft MoQ Relay Geocode August 2026
Home/Ent (NY) Relay Mesh SVC Media MS
| A --- B
| \ /
+----(16ms RTT)-------------> D
| / \
| C --- (to SVC)
* *Relay D*: JFK (NY), serves Home/Ent with 16ms RTT.
* *Relay A, B, C*: Interconnected; A connects to SVC.
* Geocode for each enables path selection (e.g., NY client → D → A →
SVC) and GDOR (e.g., ensure D and A are in permitted
jurisdictions).
Appendix B. IATA Code Reference (Informative)
IATA codes are maintained by the International Air Transport
Association. A subset useful for MoQ relay identification:
Bisht & Evens Expires 5 February 2027 [Page 11]
Internet-Draft MoQ Relay Geocode August 2026
+======+==============================+
| Code | City/Region |
+======+==============================+
| JFK | New York (John F. Kennedy) |
+------+------------------------------+
| LGA | New York (LaGuardia) |
+------+------------------------------+
| EWR | Newark (NYC metro) |
+------+------------------------------+
| IAD | Washington Dulles (Virginia) |
+------+------------------------------+
| DCA | Washington Reagan |
+------+------------------------------+
| LHR | London Heathrow |
+------+------------------------------+
| FRA | Frankfurt |
+------+------------------------------+
| CDG | Paris Charles de Gaulle |
+------+------------------------------+
| AMS | Amsterdam |
+------+------------------------------+
| NRT | Tokyo Narita |
+------+------------------------------+
| SIN | Singapore |
+------+------------------------------+
| SYD | Sydney |
+------+------------------------------+
| GRU | Sao Paulo |
+------+------------------------------+
Table 1
Operators SHOULD use the official IATA code list for authoritative
mappings.
Appendix C. Relay Advertisement Format (Informative)
The JSON schema and example for relay geocode advertisement are
defined in the related document moq-relay-geocode-advertisement-
format.md, which accompanies this draft. Implementations may use
that schema when advertising geocode via Option 2 (PUBLISH/
SUBSCRIBE), Option 3 (Catalog), Option 4 (Metrics), or Option 5
(Discovery).
Bisht & Evens Expires 5 February 2027 [Page 12]
Internet-Draft MoQ Relay Geocode August 2026
Acknowledgments
The authors thank the participants of the Media over QUIC Working
Group for discussion and review feedback that helped shape this
document.
Authors' Addresses
Altanai Bisht
Cisco Meraki
Email: albisht@cisco.com
Tim Evens
Cisco
Email: tievens@cisco.com
Bisht & Evens Expires 5 February 2027 [Page 13]