From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8042.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc8042.txt (limited to 'doc/rfc/rfc8042.txt') diff --git a/doc/rfc/rfc8042.txt b/doc/rfc/rfc8042.txt new file mode 100644 index 0000000..18de74f --- /dev/null +++ b/doc/rfc/rfc8042.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) Z. Zhang +Request for Comments: 8042 L. Wang +Updates: 2328 Juniper Networks, Inc. +Category: Standards Track A. Lindem +ISSN: 2070-1721 Cisco Systems + December 2016 + + + OSPF Two-Part Metric + +Abstract + + This document specifies an optional OSPF protocol extension to + represent router metrics in a multi-access network in two parts: the + metric from the router to the network and the metric from the network + to the router. For such networks, the router-to-router metric for + OSPF route computation is the sum of the two parts. This document + updates RFC 2328. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8042. + +Copyright Notice + + Copyright (c) 2016 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 + (http://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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Zhang, et al. Standards Track [Page 1] + +RFC 8042 OSPF Two-Part Metric December 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 + 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 + 3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4 + 3.3. Advertising Network-to-Router Traffic Engineering (TE) + Metric . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5 + 3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5 + 3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5 + 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 6.2. Informative References . . . . . . . . . . . . . . . . . 7 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 + +1. Introduction + + With Open Shortest Path First (OSPF) [RFC2328] [RFC5340]), a Network- + LSA (Link State Advertisement) is advertised to list all routers on a + broadcast network. Additionally, each router on the broadcast + network includes a link in its Router-LSA to describe its connection + to the network. The link in the Router-LSA includes a metric but the + listed routers in the Network-LSA do not include a metric. This is + based on the assumption that from a particular router, all others on + the same network can be reached with the same metric. + + With some broadcast networks, different routers can be reached with + different metrics. [RFC6845] extends the OSPF protocol with a hybrid + interface type for that kind of broadcast network, where no Network- + LSA is advertised and Router-LSAs simply include point-to-point links + to all routers on the same network with individual metrics. + Broadcast capability is still used to optimize database + synchronization and adjacency maintenance. + + This works well for broadcast networks where the metric between + different pairs of routers are really independent, for example, + Virtual Private LAN Service (VPLS) networks. + + With certain types of broadcast networks, further optimization can be + made to reduce the size of Router-LSAs and the number of updates. + + + +Zhang, et al. Standards Track [Page 2] + +RFC 8042 OSPF Two-Part Metric December 2016 + + + Consider a satellite radio network with fixed and mobile ground + terminals. All communication goes through the satellite. When the + mobile terminals move about, their communication capability may + change. When OSPF runs over the radio network, [RFC6845] hybrid + interface can be used, but with the following drawbacks. + + Consider that one terminal/router moves into an area where its + communication capability degrades significantly. Through the radio + control protocol, all other routers determine that the metric to this + particular router changed and they all need to update their Router- + LSAs accordingly. In addition, the router in question determines + that its metric to reach all others also changed and it needs to + update its Router-LSA. Consider that there could be many terminals + and many of them can be moving fast and frequently. The number and + frequency of updates of those large Router-LSAs could inhibit network + scaling. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Proposed Enhancement + + Notice that in the above scenario, when one terminal's communication + capability changes, its metric to all other terminals and the metric + to it from all other terminals will all change in a similar fashion. + Given this, the above problem can be easily addressed by breaking the + metric into two parts: the metric to the satellite and the metric + from the satellite. The metric from terminal R1 to R2 would be the + sum of the metric from R1 to the satellite and the metric from the + satellite to R2. + + Instead of using the hybrid interface type described in [RFC6845], + the network is treated as a regular broadcast network. A router on + the network no longer lists individual metrics to each neighbor in + its Router-LSA. Instead, each router advertises the metric from the + network to itself in addition to the normal metric for the network. + With the normal Router-to-Network and additional Network-to-Router + metrics advertised for each router, individual Router-to-Router + metrics can be calculated. + + With the proposed enhancement, the size of the Router-LSA will be + significantly reduced. In addition, when a router's communication + capability changes, only that router needs to update its Router-LSA. + + + + + +Zhang, et al. Standards Track [Page 3] + +RFC 8042 OSPF Two-Part Metric December 2016 + + + Note that while the example uses the satellite as the relay point at + the radio level (layer 2), the satellite does not participate in + packet forwarding at layer 3. In fact, the satellite does not need + to run any layer-3 protocol. Therefore, for generality, the metric + is abstracted as to/from the "network" rather than specifically to/ + from the "satellite". + +3. Specifications + + The following specifications are added to or modified from the base + OSPF protocol. If an area contains one or more two-part metric + networks, then all routers in the area MUST support the extensions + specified herein. This is ensured by procedures described in + Section 3.7. + +3.1. Router Interface Parameters + + The "Router interface parameters" have the following additions: + + o Two-part metric: TRUE if the interface connects to a multi-access + network that uses a two-part metric. All routers connected to the + same network SHOULD have the same configuration for their + corresponding interfaces. + + o Interface input cost: Link-state metric from the two-part-metric + network to this router. Defaults to "Interface output cost" but + is not valid for normal networks using a single metric. May be + configured or dynamically adjusted to a value different from the + "Interface output cost". + +3.2. Advertising Network-to-Router Metric in OSPFv2 + + For OSPFv2, the Network-to-Router metric is encoded in an OSPF + Extended Link TLV Sub-TLV [RFC7684], defined in this document as the + Network-to-Router Metric Sub-TLV. The type of the sub-TLV is 4. The + length of the sub-TLV is 4 (for the value part only). The value part + of the sub-TLV is defined as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MT-ID | 0 | MT Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Multiple such sub-TLVs can exist in a single OSPF Extended Link TLV, + one for each topology [RFC4915]. Each sub-TLV will have a unique + Multi-Topology Identifier (MT-ID) and will adhere to the + advertisement rules defined in Section 3.4 of [RFC4915]. The OSPF + + + +Zhang, et al. Standards Track [Page 4] + +RFC 8042 OSPF Two-Part Metric December 2016 + + + Extended Link TLV identifies the transit link to the network and is + part of an OSPFv2 Extended-Link Opaque LSA. The sub-TLV MUST ONLY + appear in Extended-Link TLVs for Link Type 2 (link to transit + network) and MUST be ignored if received for other link types. + +3.3. Advertising Network-to-Router Traffic Engineering (TE) Metric + + A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, + similar to the Traffic Engineering Metric Sub-TLV defined in + Section 2.5.5 of [RFC3630]. The only difference is the TLV type, + which is 35. The sub-TLV MUST only appear in Type 2 Link TLVs + (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs + (OSPFv3) [RFC5329], and MUST appear at most once in such a Link TLV. + +3.4. Advertising Network-to-Router Metric in OSPFv3 + + Network-to-Router metric advertisement in OSPFv3 Extended Router-LSA + [OSPFV3-EXTENDED-LSA] will be described in a separate document. + +3.5. OSPF Stub Router Behavior + + When an OSPF router with interfaces to multi-access networks using + two-part metrics is advertising itself as a stub router [RFC6987], + only the Router-to-Network metric in the stub router's OSPF Router- + LSA links for those networks is set to the MaxLinkMetric. This is + fully backward compatible and will result in the same behavior as + described in [RFC6987]. + +3.6. SPF Calculation + + The first stage of the shortest-path tree calculation is described in + Section 16.1 of [RFC2328]. With a two-part metric, when a vertex V + corresponding to a Network-LSA has just been added to the Shortest + Path Tree (SPT) and an adjacent vertex W (joined by a link in V's + corresponding Network-LSA) is being added to the candidate list, the + cost from V to W (W's network-to-router cost) is determined as + follows: + + o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque + LSA with an Extended Link TLV for the link from W to V, and the + Extended Link TLV has a Network-to-Router Metric Sub-TLV for the + corresponding topology, then the cost from V to W is the metric in + the sub-TLV. Otherwise, the cost is 0. + + o OSPFv3 [RFC5340] Shortest Path First (SPF) changes will be + described in a separate document. + + + + + +Zhang, et al. Standards Track [Page 5] + +RFC 8042 OSPF Two-Part Metric December 2016 + + +3.7. Backward Compatibility + + Due to the change of procedures in the SPF calculation, all routers + in an area that includes one or more two-part metric networks must + support the changes specified in this document. To ensure that, if + an area is provisioned to support two-part metric networks, all + routers supporting this capability must advertise a Router + Information (RI) LSA with a Router Functional Capabilities TLV + [RFC7770] that includes the following Router Functional Capability + Bit: + + Bit Capabilities + + 6 Two-Part Metric support + + Upon detecting the presence of a reachable Router-LSA without a + companion RI LSA that has the bit set, all routers MUST recalculate + routes without considering any network-to-router costs. + +4. IANA Considerations + + IANA has made the following assignments per this document: + + o Two-Part Metric support (6) was added to the "OSPF Router + Informational Capability Bits" registry. + + o Network-to-Router Metric Sub-TLV (4) has been added to the "OSPFv2 + Extended Link TLV Sub-TLVs" registry. + + o Network-to-Router TE Metric Sub-TLV (35) has been added to the + "Types for sub-TLVs of TE Link TLV (Value 2)" registry. + +5. Security Considerations + + This document does not introduce new security risks. Existing + security considerations in OSPFv2 and OSPFv3 apply. + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 6] + +RFC 8042 OSPF Two-Part Metric December 2016 + + +6. References + +6.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, + . + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + DOI 10.17487/RFC2328, April 1998, + . + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + . + + [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, + . + + [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., + "Traffic Engineering Extensions to OSPF Version 3", + RFC 5329, DOI 10.17487/RFC5329, September 2008, + . + + [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., + Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute + Advertisement", RFC 7684, DOI 10.17487/RFC7684, November + 2015, . + + [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and + S. Shaffer, "Extensions to OSPF for Advertising Optional + Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, + February 2016, . + +6.2. Informative References + + [OSPFV3-EXTENDED-LSA] + Lindem, A., Mirtorabi, S., and A. Roy, "OSPFv3 LSA + Extendibility", Work in Progress, draft-ietf-ospf-ospfv3- + lsa-extend-13.txt, October 2016. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, + . + + + +Zhang, et al. Standards Track [Page 7] + +RFC 8042 OSPF Two-Part Metric December 2016 + + + [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast + and Point-to-Multipoint Interface Type", RFC 6845, + DOI 10.17487/RFC6845, January 2013, + . + + [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. + McPherson, "OSPF Stub Router Advertisement", RFC 6987, + DOI 10.17487/RFC6987, September 2013, + . + +Acknowledgements + + The authors would like to thank Abhay Roy, Hannes Gredler, Peter + Psenak, and Eric Wu for their comments and suggestions. + +Contributors + + David Dubois + General Dynamics C4S + 400 John Quincy Adams Road + Taunton, MA 02780 + United States of America + Email: dave.dubois@gd-ms.com + + Vibhor Julka + Individual Contributor + + Email: vjulka1@yahoo.com + + + Tom McMillan + L3 Communications, Linkabit + 9890 Towne Centre Drive + San Diego, CA 92121 + United States of America + Email: tom.mcmillan@l-3com.com + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 8] + +RFC 8042 OSPF Two-Part Metric December 2016 + + +Authors' Addresses + + Zhaohui Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: zzhang@juniper.net + + + Lili Wang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: liliw@juniper.net + + + Acee Lindem + Cisco Systems + 301 Midenhall Way + Cary, NC 27513 + United States of America + + Email: acee@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 9] + -- cgit v1.2.3