Logging over Media over QUIC Transport (original) (raw)

Logging over Media over QUIC Transport

draft-jennings-moq-log-00

• Status
• Email expansions
• History

Versions:

Network Working Group C. Jennings Internet-Draft Cisco Intended status: Informational 7 July 2024 Expires: 8 January 2025

             Logging over Media over QUIC Transport
                   draft-jennings-moq-log-00

Abstract

Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media.

This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 8 January 2025.

Copyright Notice

Copyright (c) 2024 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

Jennings Expires 8 January 2025 [Page 1] Internet-Draft moqt-log July 2024

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 . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Resource ID . . . . . . . . . . . . . . . . . . . . . . . 3

3. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4. Object Data . . . . . . . . . . . . . . . . . . . . . . . . . 3

5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6. Security Considerations . . . . . . . . . . . . . . . . . . . 4

7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4

8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5

9. Introduction

The idea is each device that was logging would publish each log message as an MOQT object. The devices or systems publishing the logs are referred to as resources and have an unique ResourceID. The URLs for the objects would be set up such that a subscriber could subscribe to each resource creating logs separately, and could pick the log priority level in the subscriptions. The log collector would subscribe to the logs from the appropriate Resources that the collector wished to monitor.

The data model used is consistent with the "OpenTelemetry Specification" [OTEL] (see https://opentelemetry.io/docs/specs/otel/logs/data-model/) (https://opentelemetry.io/docs/specs/otel/logs/data-model/)) and a superset of the [RFC5424] data model for logging.

[RFC5424] specifies a layered architecture that provides for support of any number of transport layer mappings for transmitting syslog messages. This document describes the MOQT transport mapping for the syslog protocol.

1. Terminology

Jennings Expires 8 January 2025 [Page 2] Internet-Draft moqt-log July 2024

2.1. Resource ID

Each Resource that creates logs has a unique resourceID. This is created by taking the MAC address of the primary network interface in binary, computing the SHA1 hash of it, then truncating to lower 64 bits. Note the SHA1 does not provide any security priories, it is just a hash that is widely implemented in hardware. If this is not possible, any other random stable 64 bit identifier may be used. The advantage of us MAC address is that many other management systems use this address and using it makes it easier to correlate with other systems. The disadvantage is that it reveals the MAC address.

1. Naming

The Namespace used is "moq://moq-syslog.arpa/logs-v1/"

The Track name used is the binary resourceID followed by a single byte that has the log priority level in binary. Following the pattern:

<resourceID>/<log_level>

The MOQT Group ID is timestamp (explain in the next section) in the message truncated to a 62 bit binary integer.

The MOQT Object ID is zero unless more than one message is produced in the same microseconds in which case they each will get their own object number.

1. Object Data

The object payload is a JSON [RFC8259] object with the following optional fields:

• severity: As defined in [RFC5424]. Encoded as string "Emergency", "Alert", ... "Debug". This is called ServerText in [OTEL].

• timestamp: single integer with number of microseconds since "1 Jan 1972" using NTP Era zero conventions.

• pri: As defined in [RFC5424]. Numeric value from 0 to 23 and default is 1 if not present.

• hostname: As defined in [RFC5424]. Note this might not be a hostname.

• appname: As defined in [RFC5424].

Jennings Expires 8 January 2025 [Page 3] Internet-Draft moqt-log July 2024

• procid: As defined in [RFC5424].

• msgid: As defined in [RFC5424].

• msg: As defined in [RFC5424]. This is a UTF-8 string.

Any other fields are treated as structured data as defined in [RFC5424] and include:

• TraceID: Used in [OTEL] and defined in [CRD-trace-context-2-20240328].

• SpanID: As defined in [OTEL].

• InstrumentationScope: As defined in [OTEL].

Any other fields are treated as "Attributes" when mapped to [OTEL].

1. IANA

TBD

1. Security Considerations

TBD

1. Examples

On 31 Dec 1999 UTC a server produces the log message "shutting down for Y2K" with severity INFO. The timestamp for this would be 3,155,587,200. The JSON data would be:

{ "timestamp":3155587200, "severity":"Info", "msg":"shutting down forY2K" }

1. References

8.1. Normative References

[I-D.ietf-moq-transport] Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-04, 29 May 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-moq- transport-04>.

Jennings Expires 8 January 2025 [Page 4] Internet-Draft moqt-log July 2024

[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, https://www.rfc-editor.org/info/rfc5424.

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

8.2. Informative References

[CRD-trace-context-2-20240328] Kanzhelev, S., Dyla, D., Shkuro, Y., Sundaram, J. K., and B. Krol, "Trace Context Level 2", W3C CRD-trace-context- 2-20240328, 28 March 2024, <https://www.w3.org/TR/2024/ CRD-trace-context-2-20240328/>.

[OTEL] Ruech, A., "OpenTelemetry Specification 1.34.0", 11 June 2024, https://opentelemetry.io/docs/specs/otel/logs/.

Appendix A. Acknowledgments

Thanks to Suhas Nandakumar and Tim Evens for contributions and suggestions to this specification.

Author's Address

Cullen Jennings Cisco Canada Email: fluffy@iii.ca

Jennings Expires 8 January 2025 [Page 5]