Internet-Draft OSPF-GT January 2023
Lindem, et al. Expires 7 July 2023 [Page]
Workgroup:
LSR Workgroup
Internet-Draft:
draft-ietf-lsr-ospf-transport-instance-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Lindem
Cisco Systems
Y. Qu
Futurewei
A. Roy
Arrcus, Inc.
S. Mirtorabi
Cisco Systems

OSPF-GT (Generalized Transport)

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

This Internet-Draft will expire on 7 July 2023.

Table of Contents

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.

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:

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.

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.

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 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:

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.
  • 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
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:


   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

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.

          +-------------+-----------------------------------+
          | 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. and RFC Publisher, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328]
Moy, J. and RFC Publisher, "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630]
Katz, D., Kompella, K., Yeung, D., and RFC Publisher, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, , <https://www.rfc-editor.org/info/rfc3630>.
[RFC4915]
Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., Pillay-Esnault, P., and RFC Publisher, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, , <https://www.rfc-editor.org/info/rfc4915>.
[RFC5250]
Berger, L., Bryskin, I., Zinin, A., Coltun, R., and RFC Publisher, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, , <https://www.rfc-editor.org/info/rfc5250>.
[RFC5340]
Coltun, R., Ferguson, D., Moy, J., Lindem, A., and RFC Publisher, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, , <https://www.rfc-editor.org/info/rfc5340>.
[RFC6549]
Lindem, A., Roy, A., Mirtorabi, S., and RFC Publisher, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, , <https://www.rfc-editor.org/info/rfc6549>.
[RFC6823]
Ginsberg, L., Previdi, S., Shand, M., and RFC Publisher, "Advertising Generic Information in IS-IS", RFC 6823, DOI 10.17487/RFC6823, , <https://www.rfc-editor.org/info/rfc6823>.
[RFC8174]
Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362]
Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., Baker, F., and RFC Publisher, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, , <https://www.rfc-editor.org/info/rfc8362>.

10.2. Informative References

[ETSI-WP28-MEC]
Sami Kekki, etc., "MEC in 5G Networks", , <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, , <http://www.ietf.org/internet-drafts/draft-wang-lsr-igp-extensions-ifit-01.txt>.
[RFC2334]
Luciani, J., Armitage, G., Halpern, J., Doraswamy, N., and RFC Publisher, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, DOI 10.17487/RFC2334, , <https://www.rfc-editor.org/info/rfc2334>.
[RFC5572]
Blanchet, M., Parent, F., and RFC Publisher, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, DOI 10.17487/RFC5572, , <https://www.rfc-editor.org/info/rfc5572>.

Authors' Addresses

Acee Lindem
Cisco Systems
301 Midenhall Way
CARY, NC 27513
United States
Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Abhay Roy
Arrcus, Inc.
Sina Mirtorabi
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America