summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8042.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8042.txt')
-rw-r--r--doc/rfc/rfc8042.txt507
1 files changed, 507 insertions, 0 deletions
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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+ DOI 10.17487/RFC2328, April 1998,
+ <http://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,
+ <http://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,
+ <http://www.rfc-editor.org/info/rfc4915>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc5329>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7684>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7770>.
+
+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,
+ <http://www.rfc-editor.org/info/rfc5340>.
+
+
+
+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,
+ <http://www.rfc-editor.org/info/rfc6845>.
+
+ [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
+ McPherson, "OSPF Stub Router Advertisement", RFC 6987,
+ DOI 10.17487/RFC6987, September 2013,
+ <http://www.rfc-editor.org/info/rfc6987>.
+
+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]
+