The RFC Archive
 The RFC Archive   RFC 8042   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 8042



Last modified on Wednesday, December 28th, 2016

Permanent link to RFC 8042
Search GitHub Wiki for RFC 8042
Show other RFCs mentioning RFC 8042







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/RFC 8042.

 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 top


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) [RFC 2328] [RFC 5340]), 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. [RFC 6845] 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 top

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, [RFC 6845] 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 [RFC 2119]. 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 [RFC 6845], 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 top

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 [RFC 7684], 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 [RFC 4915]. 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 [RFC 4915]. The OSPF Zhang, et al. Standards Track PAGE 4 top

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 [RFC 3630]. 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) [RFC 5329], 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 [RFC 6987], 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 [RFC 6987]. 3.6. SPF Calculation The first stage of the shortest-path tree calculation is described in Section 16.1 of [RFC 2328]. 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 [RFC 5340] Shortest Path First (SPF) changes will be described in a separate document. Zhang, et al. Standards Track PAGE 5 top

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 [RFC 7770] 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 top

RFC 8042 OSPF Two-Part Metric December 2016 6. References 6.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC 2119, March 1997, <http://www.rfc-editor.org/info/RFC 2119>. [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC 2328, April 1998, <http://www.rfc-editor.org/info/RFC 2328>. [RFC 3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC 3630, September 2003, <http://www.rfc-editor.org/info/RFC 3630>. [RFC 4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC 4915, June 2007, <http://www.rfc-editor.org/info/RFC 4915>. [RFC 5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC 5329, September 2008, <http://www.rfc-editor.org/info/RFC 5329>. [RFC 7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC 7684, November 2015, <http://www.rfc-editor.org/info/RFC 7684>. [RFC 7770] 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/RFC 7770, February 2016, <http://www.rfc-editor.org/info/RFC 7770>. 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. [RFC 5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC 5340, July 2008, <http://www.rfc-editor.org/info/RFC 5340>. Zhang, et al. Standards Track PAGE 7 top

RFC 8042 OSPF Two-Part Metric December 2016 [RFC 6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC 6845, January 2013, <http://www.rfc-editor.org/info/RFC 6845>. [RFC 6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC 6987, September 2013, <http://www.rfc-editor.org/info/RFC 6987>. 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 top

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 top

RFC TOTAL SIZE: 18496 bytes PUBLICATION DATE: Wednesday, December 28th, 2016 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 8042: The IETF Trust, Wednesday, December 28th, 2016
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement