Skip to main content

OSPF-GT (Generalized Transport)
draft-ietf-lsr-ospf-transport-instance-06

Document Type Active Internet-Draft (lsr WG)
Authors Acee Lindem , Yingzhen Qu , Abhay Roy , Sina Mirtorabi
Last updated 2023-12-19
Replaces draft-acee-lsr-ospf-transport-instance
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Christian Hopps
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to chopps@chopps.org
draft-ietf-lsr-ospf-transport-instance-06
LSR Workgroup                                                  A. Lindem
Internet-Draft                                   LabN Consulting, L.L.C.
Intended status: Standards Track                                   Y. Qu
Expires: 21 June 2024                                          Futurewei
                                                                  A. Roy
                                                            Arrcus, Inc.
                                                            S. Mirtorabi
                                                           Cisco Systems
                                                        19 December 2023

                    OSPF-GT (Generalized Transport)
               draft-ietf-lsr-ospf-transport-instance-06

Abstract

   OSPFv2 and OSPFv3 include a reliable flooding mechanism to
   disseminate routing topology and Traffic Engineering (TE) information
   within a routing domain.  Given the effectiveness of these
   mechanisms, it is advantageous to use the same mechanism for
   dissemination of other types of information within the domain.
   However, burdening OSPF with this additional information will impact
   intra-domain routing convergence and possibly jeopardize the
   stability of the OSPF routing domain.  This document presents
   mechanisms to advertise this non-routing information in separate OSPF
   Generalized Transport (OSPF-GT) instances.

   OSPF-GT is not constrained to the semantics as traditional OSPF.
   OSPF-GT neighbors are not required to be directly attached since they
   are never used to compute hop-by-hop routing.  Consequently,
   independent sparse topologies can be defined to dissemenate non-
   routing information only to those OSPF-GT routers requiring it.

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

Lindem, et al.            Expires 21 June 2024                  [Page 1]
Internet-Draft                   OSPF-GT                   December 2023

   This Internet-Draft will expire on 21 June 2024.

Copyright Notice

   Copyright (c) 2023 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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Possible Use Cases  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  MEC Service Discovery . . . . . . . . . . . . . . . . . .   4
     3.2.  Application Data Dissemination  . . . . . . . . . . . . .   4
     3.3.  Intra-Area Topology for BGP-LS Distribution . . . . . . .   5
     3.4.  BGP-LS Replacement  . . . . . . . . . . . . . . . . . . .   5
   4.  OSPF-GT Instance  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  OSPFv2 Generalized Transport Packet Differentiation . . .   5
     4.2.  OSPFv3 Generalized Transport Packet Differentiation . . .   6
     4.3.  OSPF-GT Relationship to Traditional OSPF  . . . . . . . .   6
     4.4.  Network Prioritization  . . . . . . . . . . . . . . . . .   6
     4.5.  OSPF-GT Omission of Routing Calculation . . . . . . . . .   6
     4.6.  Non-routing Instance Separation . . . . . . . . . . . . .   7
     4.7.  Non-Routing Sparse Topologies . . . . . . . . . . . . . .   8
       4.7.1.  Remote Neighbor . . . . . . . . . . . . . . . . . . .   8
     4.8.  Multiple Topologies . . . . . . . . . . . . . . . . . . .   9
   5.  OSPF Generialized Transport Information (GTI) Encoding  . . .   9
     5.1.  OSPFv2-GT Information Encoding  . . . . . . . . . . . . .   9
     5.2.  OSPFv3-GT Information Encoding  . . . . . . . . . . . . .  10
     5.3.  Generalized Transport Information (GTI) TLV Encoding  . .  10
       5.3.1.  Top-Level GTI Application TLV . . . . . . . . . . . .  11
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . .  12
     8.2.  OSPFv3 LSA Function Code Assignment . . . . . . . . . . .  12
     8.3.  OSPF-GT Instance Information Top-Level TLV Registry . . .  12
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13

Lindem, et al.            Expires 21 June 2024                  [Page 2]
Internet-Draft                   OSPF-GT                   December 2023

     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   OSPFv2 [RFC2328] and OSPFv3 [RFC5340] include a reliable flooding
   mechanism to disseminate routing topology and Traffic Engineering
   (TE) information within a routing domain.  Given the effectiveness of
   mechanisms, it is advantageous to use the same mechanism for
   dissemination of other types of information within the domain.
   However, burdening OSPF with this additional information will impact
   intra-domain routing convergence and possibly jeopardize the
   stability of the OSPF routing domain.  This document presents
   mechanisms to advertise this non-routing information in separate OSPF
   Generalized Transport (OSPF-GT) instances.

   OSPF-GT is not constrained to the semantics as traditional OSPF.
   OSPF-GT neighbors are not required to be directly attached since they
   are never used to compute hop-by-hop routing.  Consequently,
   independent sparse topologies can be defined to dissemenate non-
   routing information only to those OSPF-GT routers requiring it.

   OSPF-GT is independent of any traditional OSPF instance.  However, it
   does rely on the reachbility calculated by routing protocls, e.g.
   OSPF and IS-IS.

   This OSPF protocol extension provides functionality similar to
   "Advertising Generic Information in IS-IS" [RFC6823].  Additionally,
   OSPF is extended to support sparse non-routing overlay topologies
   Section 4.7.  The usage of the OSPF-like flooding and synchronization
   mechanisms were originally standardized for general information
   advertisement in the Server Cache Synchronization Protocol (SCSP)
   [RFC2334].  However, SCSP never experienced significant adoption due
   to its association with the waning Asynchronous Transfer Mode (ATM)
   technology.

2.  Requirements Language

   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.

Lindem, et al.            Expires 21 June 2024                  [Page 3]
Internet-Draft                   OSPF-GT                   December 2023

3.  Possible Use Cases

3.1.  MEC Service Discovery

   Multi-Access Edge Computing (MEC) plays an important role in 5G
   architecture.  MEC optimizes the performance for ultra-low latency
   and high bandwidth services by providing networking and computing at
   the edge of the network [ETSI-WP28-MEC].  To achieve this goal, it's
   important to expose the network capabilities and services of a MEC
   device to 5G User Equipment (UE), i.e., UEs.

   The followings are an incomplete list of the kind of information that
   OSPF-GT can be used to advertise:

   *  A network service is realized using one or more physical or
      virtualized hosts in MEC, and the locations of these service
      points might change.  The auto-discovery of these service
      locations can be achieved using an OSPF-GT.

   *  UEs might be mobile, and MEC should support service continuity and
      application mobility.  This may require service state transferring
      and synchronization.  OSPF-GT can be used to synchronize these
      states.

   *  Network resources are limited, such as computing power, storage.
      The availability of such resources is dynamic, and OSPF-GT can be
      used to populate such information, so applications can pick the
      right location of such resources, hence improve user experience
      and resource utilization.

3.2.  Application Data Dissemination

   Typically a network consists of routers from different vendors with
   different capabilities, and some applications may want to know
   whether a router supports certain functionality or where to find a
   router supports a functionality, so it will be ideal if such kind of
   information is known to all routers or a group of routers in the
   network.  For example, an ingress router needs to find an egress
   router that supports In-situ Flow Information Telemetry (IFIT)
   [I-D.wang-lsr-igp-extensions-ifit] and obtain IFIT parameters.

   OSPF-GT can be used to populate such router capabilities/
   functionalities without impacting the performance or convergence of
   the base OSPF protocol.

Lindem, et al.            Expires 21 June 2024                  [Page 4]
Internet-Draft                   OSPF-GT                   December 2023

3.3.  Intra-Area Topology for BGP-LS Distribution

   In some cases, it is desirable to limit the number of BGP-LS
   [RFC5572] sessions with a controller to the a one or two routers in
   an OSPF domain.  However, many times those router(s) do not have full
   visibility to the complete topology of all the areas.  To solve this
   problem without extending the BGP-LS domain, the OSPF LSAs for non-
   local areas could be flooded over the OSPF-GT topology using remote
   neighbors Section 4.7.1.

3.4.  BGP-LS Replacement

   This mechansism could also be used to replace BGP-LS [RFC5572]
   completely by advertising the entire Link State Database (LSDB) using
   an OSPF-GT topology with the controller(s) as remote neighbors
   Section 4.7.1.  The mechanism could also be extended to advertise IS-
   IS LSPs within OSPF-GT Information LSAs as described in Section 5.
   However, the details of BGP-LS replacement are beyond the scope of
   this document.

4.  OSPF-GT Instance

   In order to isolate the effects of flooding and processing of non-
   routing information, OSPF-GT will be relegated to protocol instances
   sepearate from the traditional OSPF routing instances.  These
   instance(s) should be given lower priority when contending for router
   resources including processing, backplane bandwidth, and line card
   bandwidth.  How that is realized is an implementation issue and is
   beyond the scope of this document.

   Throughout the document, non-routing refers to routing information
   that is not used for IP or IPv6 routing calculations.  The OSPF-GT
   instances area ideally suited for generalized dissemination of other
   types of networking and applicaiton information for other protocols
   and layers.

4.1.  OSPFv2 Generalized Transport Packet Differentiation

   OSPFv2 currently does not offer a mechanism to differentiate OSPF
   packets from multiple OSPF instances (including OSPF-GT instances)
   sent and received on the same interface.  However, the [RFC6549]
   provides the necessary packet encoding to support multiple OSPF
   protocol instances.

Lindem, et al.            Expires 21 June 2024                  [Page 5]
Internet-Draft                   OSPF-GT                   December 2023

4.2.  OSPFv3 Generalized Transport Packet Differentiation

   Fortunately, OSPFv3 already supports separate instances within the
   packet encodings.  The existing OSPFv3 packet header instance ID
   field will be used to differentiate packets received on the same link
   (refer to section 2.4 in [RFC5340]).

4.3.  OSPF-GT Relationship to Traditional OSPF

   In OSPF, we must guarantee that any information we've received is
   treated as valid if and only if the router sending it is reachable.
   We'll refer to this as the "condition of reachability" in this
   document.

   OSPF-GT is not dependent on any other OSPF instance.  It does,
   however, have much of the same as topology information must be
   advertised to satisfy the "condition of reachability".

   Further optimizations and coupling between OSPF-GT and a traditional
   OSPF instance are beyond the scope of this document.  This is an area
   for future study.

4.4.  Network Prioritization

   While OSPFv2 (section 4.3 in [RFC2328]) are normally sent with IP
   precedence Internetwork Control, any packets sent using OSPF-GT
   transport instance will be sent with IP precedence Flash (B'011').
   This is only appropriate given that this is a pretty flashy
   mechanism.

   Similarly, OSPFv3 GT instance packets will be sent with the traffic
   class mapped to flash (B'011') as specified in ([RFC5340]).

   By setting the IP/IPv6 precedence differently for OSPF-GT instance
   packets, traditional OSPF routing instances can be given priority
   during both packet transmission and reception.  In fact, some router
   implementations map the IP precedence directly to their internal
   packet priority.  However, internal router implementation decisions
   are beyond the scope of this document.

4.5.  OSPF-GT Omission of Routing Calculation

   Since one of the primary advantages of the OSPF-GT is to separate the
   routing and non-routing processing and fate sharing, a OSPF-GT
   instance SHOULD NOT install any IP or IPv6 routes.  OSPF routers
   SHOULD NOT advertise any OSPF-GT LSAs containing IP or IPv6 prefixes
   and OSPF routers receiving LSAs advertising IP or IPv6 prefixes
   SHOULD ignore them.  This implies that an OSPF-GT instance Link State

Lindem, et al.            Expires 21 June 2024                  [Page 6]
Internet-Draft                   OSPF-GT                   December 2023

   Database should not include any of the LSAs as shown in Table 1.

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   OSPFv2            |  summary-LSAs (type 3)                  |
     |                     |  AS-external-LSAs (type 5)              |
     |                     |  NSSA-LSAs (type 7)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   OSPFv3            |  inter-area-prefix-LSAs (type 2003)     |
     |                     |  AS-external-LSAs (type 0x4005)         |
     |                     |  NSSA-LSAs (type 0x2007)                |
     |                     |  intra-area-prefix-LSAs (type 0x2009)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | OSPFv3 Extended LSA |  E-inter-area-prefix-LSAs (type 0xA023) |
     |                     |  E-as-external-LSAs (type 0xC025)       |
     |                     |  E-Type-7-NSSA (type 0xA027)            |
     |                     |  E-intra-area-prefix-LSA (type 0xA029)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: LSAs not included in OSPF-GT

   If these LSAs are erroneously advertised, they will be flooded as per
   standard OSPF but MUST be ignored by OSPF routers supporting this
   specification.

4.6.  Non-routing Instance Separation

   It has been suggested that an implementation could obtain the same
   level of separation between IP routing information and non-routing
   information in a single instance with slight modifications to the
   OSPF protocol.  The authors refute this contention for the following
   reasons:

   *  Adding internal and external mechanisms to prioritize routing
      information over non-routing information are much more complex
      than simply relegating the non-routing information to a separate
      instance as proposed in this specification.

   *  The instance boundary offers much better separation for allocation
      of finite resources such as buffers, memory, processor cores,
      sockets, and bandwidth.

   *  The instance boundary decreases the level of fate sharing for
      failures.  Each instance may be implemented as a separate process
      or task.

   *  With non-routing information, many times not every router in the
      OSPF routing domain requires knowledge of every piece of non-
      routing information.  In these cases, groups of routers which need

Lindem, et al.            Expires 21 June 2024                  [Page 7]
Internet-Draft                   OSPF-GT                   December 2023

      to share information can be segregated into sparse topologies
      greatly reducing the amount of non-routing information any single
      router needs to maintain.

4.7.  Non-Routing Sparse Topologies

   With non-routing information, many times not every router in the OSPF
   routing domain requires knowledge of every piece of non-routing
   information.  In these cases, groups of routers which need to share
   information can be segregated into sparse topologies.  This will
   greatly reduce the amount of information any single router needs to
   maintain with the core routers possibly not requiring any non-routing
   information at all.

   With traditional OSPF, every router in an OSPF area must have every
   piece of topological information and every intra-area IP or IPv6
   prefix.  With non-routing information, only the routers needing to
   share a set of information need be part of the corresponding sparse
   topology.  For directly attached routers, one only needs to configure
   the desired topologies on the interfaces with routers requiring the
   non-routing information.  When the routers making up the sparse
   topology are not part of a uniconnected graph, two alternatives
   exist.  The first alternative is configuring tunnels to form a fully
   connected graph including only those routers in the sparse topology.
   The second alternative is use remote neighbors as described in
   Section 4.7.1.

4.7.1.  Remote Neighbor

   With sparse topologies, OSPF-GT routers sharing non-routing
   information may not be directly connected.  OSPF-GT adjacencies with
   remote neighbors are formed exactly as they are with regular OSPF
   neighbors.  The main difference is that a remote OSPF-GT neighbor's
   address is configured and IP routing is used to deliver OSPF-GT
   protocol packets to the remote neighbor.  Other salient feature of
   the remote neighbor include:

   *  All OSPF-GT packets have the remote neighbor's configured IP
      address as the IP destination address.  This address has be to
      reachable using the unicast topology.

   *  The adjacency is represented in the router Router-LSA as a router
      (type-1) link with the link data set to the remote neighbor's
      configured IP address.

Lindem, et al.            Expires 21 June 2024                  [Page 8]
Internet-Draft                   OSPF-GT                   December 2023

   *  Similar to NBMA networks, a poll-interval is configured to
      determine if the remote neighbor is reachable.  This value is
      normally much higher than the hello interval with 40 seconds
      RECOMMENDED as the default.

4.8.  Multiple Topologies

   For some applications, the information need to be flooded only to a
   topology which is a subset of routers of the OSPF-GT instance.  This
   allows the application specific information only to be flooded to
   routers that support the application.  An OSPF-GT instance may
   support multiple topologies as defined in [RFC4915].  But as pointed
   out in Section 4.5, an OSPF-GT instance or topology SHOULD NOT
   install any IP or IPv6 routes.

   Each topology associated with the OSPF-GT instance MUST be fully
   connected in order for the LSAs to be successfully flooded to all
   routers in the topology.

5.  OSPF Generialized Transport Information (GTI) Encoding

5.1.  OSPFv2-GT Information Encoding

   Application specific information will be flooded in opaque LSAs as
   specified in [RFC5250].  An Opaque LSA option code will be reserved
   for Generalized Transport Information (GTI) as described in
   Section 8.  The GTI LSA can be advertised at any of the defined
   flooding scopes (link, area, or autonomous system (AS)).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            LS age             |     Options   |  9, 10, or 11 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       TBD1    |     Opaque ID (Instance ID)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Advertising Router                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     LS sequence number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         LS checksum           |             length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-                            TLVs                             -+
     |                             ...                               |

   g

Lindem, et al.            Expires 21 June 2024                  [Page 9]
Internet-Draft                   OSPF-GT                   December 2023

                 Figure 2: OSPFv2-GT Information Opaque LSA

   The format of the TLVs within the body of an GTI LSA is as defined in
   Section 5.3.

5.2.  OSPFv3-GT Information Encoding

   Application specific information will be flooded in separate LSAs
   with a separate function code.  Refer to section A.4.2.1 of
   [RFC5340].  for information on the LS Type encoding in OSPFv3, and
   section 2 of [RFC8362] for OSPFv3 extended LSA types.  An OSPFv3
   function code will be reserved for Generalized Transport Information
   (GTI) as described in Section 8.  Same as OSPFv2-GT, the GTI LSA can
   be advertised at any of the defined flooding scopes (link, area, or
   autonomous system (AS)).  The U bit will be set indicating that
   OSPFv3 GTI LSAs should be flooded even if it is not understood.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            LS age             |1|S12|          TBD2           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Link State ID (Instance ID)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Advertising Router                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       LS sequence number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        LS checksum            |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +-                            TLVs                             -+
     |                             ...                               |

                    Figure 3: OSPFv3-GT Information LSA

   The format of the TLVs within the body of an GTI LSA is as defined in
   Section 5.3.

5.3.  Generalized Transport Information (GTI) TLV Encoding

   The format of the TLVs within the body of the LSAs containing non-
   routing information is the same as the format used by the Traffic
   Engineering Extensions to OSPF [RFC3630].  The LSA payload consists
   of one or more nested Type/Length/Value (TLV) triplets.  The format
   of each TLV is:

Lindem, et al.            Expires 21 June 2024                 [Page 10]
Internet-Draft                   OSPF-GT                   December 2023

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Value...                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 4: TLV Format

5.3.1.  Top-Level GTI Application TLV

   An Application top-level TLV will be used to encapsulate application
   data advertised within GTI LSAs.  This top-level TLV may be used to
   handle the local publication/subscription for application specific
   data.  The details of such a publication/subscription mechanism are
   beyond the scope of this document.  An Application ID is used in the
   top-level application TLV and shares the same code point with IS-IS
   as defined in [RFC6823].

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type (1)         |      Length - Variable        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Application ID             |       Reserved                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            Sub-TLVs                           .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Application ID:
       An identifier assigned to this application via the IANA registry,
       as defined in RFC 6823 [RFC6823]. Each unique application will
       have a unique ID.

     Additional Application-Specific Sub-TLVs:
       Additional information defined by applications can be encoded as
       Sub-TLVs. Definition of such information is beyond the scope of
       this document.

                          Figure 5: Top-Level TLV

Lindem, et al.            Expires 21 June 2024                 [Page 11]
Internet-Draft                   OSPF-GT                   December 2023

   The specific TLVs and sub-TLVs relating to a given application and
   the corresponding IANA considerations MUST be specified in the
   document corresponding to that application.

6.  Manageability Considerations

   Since OSPF-GT is partioned into one of more separate instances, all
   the existing OSPF management information will be available for that
   instance.  This will enabled ease in managing individual
   applications.  Additionally, an the operational data for OSPF-GT LSAs
   should include an indication of whether or not the "condition of
   reachability" is met for the application.

   It is RECOMMENDED that reachability for remote neighors Section 4.7.1
   through the unicast topology be reported as part of the operational
   data.

7.  Security Considerations

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.  Document availing
   OSPF-GT for non-routing information dissemination MUST documents the
   Security Considerations pertaining to this information.

8.  IANA Considerations

8.1.  OSPFv2 Opaque LSA Type Assignment

   IANA is requested to assign an option type, TBD1, for Generalized
   Transport Information (GTI) LSA from the "Opaque Link-State
   Advertisements (LSA) Option Types" registry.

8.2.  OSPFv3 LSA Function Code Assignment

   IANA is requested to assign a function code, TBD2, for Generalized
   Transport Information (GTI) LSAs from the "OSPFv3 LSA Function Codes"
   registry.

8.3.  OSPF-GT Instance Information Top-Level TLV Registry

   IANA is requested to create a registry for OSPF Generalized Transport
   Information (GTI) Top-Level TLVs.  The first available TLV (1) is
   assigned to the Application TLV Section 5.3.  The allocation of the
   unsigned 16-bit TLV type are defined in the table below.

Lindem, et al.            Expires 21 June 2024                 [Page 12]
Internet-Draft                   OSPF-GT                   December 2023

             +-------------+-----------------------------------+
             | Range       | Assignment Policy                 |
             +-------------+-----------------------------------+
             | 0           | Reserved (Not to be assigned)     |
             |             |                                   |
             | 1           | Application TLV                   |
             |             |                                   |
             | 2-16383     | Unassigned (IETF Review)          |
             |             |                                   |
             | 16383-32767 | Unassigned (FCFS)                 |
             |             |                                   |
             | 32768-32777 | Experimentation (No assignements) |
             |             |                                   |
             | 32778-65535 | Reserved (Not to be assigned)     |
             +-----------+-------------------------------------+

              Figure 6: GTI Top-Level TLV Registry Assignments

9.  Acknowledgement

   The authors would like to thank Les Ginsberg for review and comments.

10.  References

10.1.  Normative References

   [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/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
              July 2008, <https://www.rfc-editor.org/info/rfc5250>.

Lindem, et al.            Expires 21 June 2024                 [Page 13]
Internet-Draft                   OSPF-GT                   December 2023

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

   [RFC6549]  Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
              Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
              March 2012, <https://www.rfc-editor.org/info/rfc6549>.

   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
              Generic Information in IS-IS", RFC 6823,
              DOI 10.17487/RFC6823, December 2012,
              <https://www.rfc-editor.org/info/rfc6823>.

   [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/info/rfc8174>.

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

10.2.  Informative References

   [ETSI-WP28-MEC]
              Sami Kekki, etc., "MEC in 5G Networks", 2018,
              <https://www.etsi.org/images/files/ETSIWhitePapers/
              etsi_wp28_mec_in_5G_FINAL.pdf>.

   [I-D.wang-lsr-igp-extensions-ifit]
              Wang, Y., Zhou, T., Qin, F., Chen, H., and R. Pang, "IGP
              Extensions for In-situ Flow Information Telemetry (IFIT)
              Capability Advertisement", Work in Progress, Internet-
              Draft, draft-wang-lsr-igp-extensions-ifit-01, 28 July
              2020, <http://www.ietf.org/internet-drafts/draft-wang-lsr-
              igp-extensions-ifit-01.txt>.

   [RFC2334]  Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy,
              "Server Cache Synchronization Protocol (SCSP)", RFC 2334,
              DOI 10.17487/RFC2334, April 1998,
              <https://www.rfc-editor.org/info/rfc2334>.

   [RFC5572]  Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
              Tunnel Setup Protocol (TSP)", RFC 5572,
              DOI 10.17487/RFC5572, February 2010,
              <https://www.rfc-editor.org/info/rfc5572>.

Lindem, et al.            Expires 21 June 2024                 [Page 14]
Internet-Draft                   OSPF-GT                   December 2023

Authors' Addresses

   Acee Lindem
   LabN Consulting, L.L.C.
   301 Midenhall Way
   CARY, NC 27513
   United States
   Email: acee.ietf@gmail.com

   Yingzhen Qu
   Futurewei
   2330 Central Expressway
   Santa Clara, CA 95050
   United States of America
   Email: yingzhen.qu@futurewei.com

   Abhay Roy
   Arrcus, Inc.
   Email: abhay@arrcus.com

   Sina Mirtorabi
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: smirtora@cisco.com

Lindem, et al.            Expires 21 June 2024                 [Page 15]