Open Shortest Path First Z. Zhang
Internet-Draft L. Wang
Updates: 2328, 5340 (if approved) Juniper Networks, Inc.
Intended status: Standards Track D. Dubois
Expires: April 5, 2015 General Dynamics C4S
V. Julka
T. McMillan
L3 Communications, Linkabit
October 2, 2014
OSPF Two-part Metric
draft-zzhang-ospf-two-part-metric-03.txt
Abstract
This document specifies an optional extension to the OSPF protocol,
to represent the metric on a multi-access network as two parts: the
metric from a router to the network, and the metric from the network
to the router. The router to router metric would be the sum of the
two.
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.
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 http://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 April 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
Zhang, et al. Expires April 5, 2015 [Page 1]
Internet-Draft ospf-two-part-metric October 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . . 3
3. Speficications . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router metric in OSPFv2 . . . . . . 5
3.3. Advertising Network-to-Router metric in OSPFv3 . . . . . . 5
3.4. SPF Calculation . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Backward Compatibility . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Zhang, et al. Expires April 5, 2015 [Page 2]
Internet-Draft ospf-two-part-metric October 2014
1. Introduction
For a broadcast network, a Network LSA is advertised to list all
routers on the network, and each router on the 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 does 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 networks, with which no
Network LSA is used and routers simply includes p2p links to all
routers on the same network with individual metrics. Broadcast
capability is still utilized to optimize database synchronization and
adjacency maintenance.
That works well for broadcast networks on which metric between
different pair of routers are really independent. For example, VPLS
networks.
With certain types of broadcast networks, further optimization can be
made to reduce the size of the Router LSAs and number of updates.
Consider a satellite radio network with fixed and mobile ground
terminals. All communication go through the satellite. When the
mobile terminals move about, their communication capability may
change. When OSPF runs over the radio network (routers being or in
tandem with the terminals), RFC 6845 hybrid interface can be used,
but with the following drawbacks.
Consider that one terminal/router moves into an area where
communication capability degrades significantly. Through the radio
control protocol all other routers determine that the metric to this
particular one changed and they all need to update their Router LSAs
accordingly. The router in question also determines that its metric
to reach all others also changed and it also need to update its
Router LSA. Consider that there could be many terminals and many of
them can be moving fast and frequently, the number/frequency of
updates of those large Router LSAs could become inhibiting.
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
from all other terminals to it will all change in a similar fashion.
Given this, the above problem can be easily addressed by breaking the
Zhang, et al. Expires April 5, 2015 [Page 3]
Internet-Draft ospf-two-part-metric October 2014
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.
Now instead of using the RFC6845 hybrid interface type, the network
is just treated as a regular broadcast one. A router on the network
no longer needs to list individual metrics to each neighbors in its
Router LSA. In case of symmetric metric to/from the satellite, it is
represented by the transit link's metric in the Router LSA. In case
of asymetric metric, it is rerepresented by a special MT Metric
(Section 3).
With the proposed enhancement, the size of Router LSA will be
significantly reduced. In addition, when a router's communication
capability changes, only that router needs to update its Router LSA.
Note that while the example uses the satellite as the relay point at
radio level (layer 2), at layer 3 the satellite does not play any
role. It does not need to be running layer 3 protocol at all.
Therefore for generality, the metric is abstracted as to/from the
"network" rather that specifically to/from the "satellite".
3. Speficications
The following protocol 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 here. This document does not currently specify
a way to detect a router's capability of supporting this, and relies
on operator's due diligence in provisioning. A protocol mechanism
may be developer in the future.
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 two-part metric.
o Interface input cost: Link state metric from the network to this
router. Defaulted to "Interface output cost". May be configured
or dynamically adjusted to a value different from the "Interface
output cost". If different from the output cost, it MUST be
advertised in addition to the link (output) cost for this
interface in the router's Router LSA.
Zhang, et al. Expires April 5, 2015 [Page 4]
Internet-Draft ospf-two-part-metric October 2014
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 [ietf-ospf-lsa-extend], defined in this
document as Network-to-Router Metric Sub-TLV. The type of the Sub-
TLV is TBD. The length of the Sub-TLV is 4 (for the value part
only). The value part of the Sub-TLV is defined as the following:
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 | 0 | MT metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple such Sub-TLV can exist in a single OSPF Extended Link TLV,
one for each topology. The OSPF Extended Link TLV identifies the
transit link to the network, and is part of a OSPFv2 Extended Link
Opaque LSA.
3.3. Advertising Network-to-Router metric in OSPFv3
For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is
used, though it is part of the Router-Link TLV of E-Router-LSA [ietf-
ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not
defined so the only valid value for the MT field is 0 and only one
such Sub-TLV exist in the Router-Link TLV.
3.4. SPF Calculation
During the first stage of shortest-path tree calculation for an area,
when a vertex V corresponding to a Network LSA is added to the
shortest-path tree and its adjacent vertex W (joined by a link in V's
corresponding Network LSA), the cost from V to W, which is W's
network-to-router cost, is determined the following way:
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 For OSPFv3, if vertex W has a corresponding E-Router-LSA with a
Router-Link TLV for the link from W to V, and the Router-Link TLV
has a Network-to-Router Metric Sub-TLV, then the cost from V to W
is the metric in the Sub-TLV. If not, the cost is 0.
Zhang, et al. Expires April 5, 2015 [Page 5]
Internet-Draft ospf-two-part-metric October 2014
3.5. 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 Router Information
(RI) LSA with a newly assigned bit set in Router Informational
Capabilities TLV:
Bit Capabilities
0-5 Various alreay assigned bits
6 OSPF Two-part Metric [TPM]
Upon detecting the presence of a reachable Router LSA without a
companion RI LSA that has the bit set, all routers MUST disable the
two-part metric functionalities and take the following actions:
o If this router advertised network-to-router costs before, remove
the stub links in OSPFv2 or secondary prefix entries in OSPFv3
that are used for that purpose, and update the metric in the
primary prefix entry to 0.
o Recalculate routes w/o considering any network-to-router costs.
4. IANA Considerations
This document requests IANA to assigna a new bit in the Router
Informational Capabilities TLV to indicate the capability of
supporting two-part metric.
5. Security Considerations
This document does not introduce new security risks.
6. Acknowledgements
The authors would like to thank Acee Lindem, Abhay Roy, Hannes
Gredler, Peter Psenak and Eric Wu for their comments and suggestions.
7. References
7.1. Normative References
[I-D.ietf-ospf-lsa-extend] Psenak, P., Previdi, S., Filsfils,
C., Gredler, H., Shakir, R.,
Henderickx, W., Tantsura, J., and
Zhang, et al. Expires April 5, 2015 [Page 6]
Internet-Draft ospf-two-part-metric October 2014
A. Lindem, "OSPFv2 LSA
Extendibility",
draft-ietf-ospf-lsa-extend-00
(work in progress), August 2014.
[I-D.ietf-ospf-ospfv3-lsa-extend] Lindem, A., Mirtorabi, S., Roy,
A., and F. Baker, "OSPFv3 LSA
Extendibility", draft-ietf-ospf-
ospfv3-lsa-extend-04 (work in
progress), September 2014.
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54,
RFC 2328, April 1998.
[RFC4915] Psenak, P., Mirtorabi, S., Roy,
A., Nguyen, L., and P. Pillay-
Esnault, "Multi-Topology (MT)
Routing in OSPF", RFC 4915,
June 2007.
[RFC4970] Lindem, A., Shen, N., Vasseur,
JP., Aggarwal, R., and S. Shaffer,
"Extensions to OSPF for
Advertising Optional Router
Capabilities", RFC 4970,
July 2007.
[RFC5340] Coltun, R., Ferguson, D., Moy, J.,
and A. Lindem, "OSPF for IPv6",
RFC 5340, July 2008.
[RFC5613] Zinin, A., Roy, A., Nguyen, L.,
Friedman, B., and D. Yeung, "OSPF
Link-Local Signaling", RFC 5613,
August 2009.
7.2. Informative References
[RFC6845] Sheth, N., Wang, L., and J. Zhang,
"OSPF Hybrid Broadcast and Point-
to-Multipoint Interface Type",
RFC 6845, January 2013.
Zhang, et al. Expires April 5, 2015 [Page 7]
Internet-Draft ospf-two-part-metric October 2014
Authors' Addresses
Jeffrey Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
EMail: zzhang@juniper.net
Lili Wang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
EMail: liliw@juniper.net
David Dubois
General Dynamics C4S
400 John Quincy Adams Road
Taunton, MA 02780
EMail: dave.dubois@gdc4s.com
Vibhor Julka
L3 Communications, Linkabit
9890 Towne Centre Drive
San Diego, CA 92121
EMail: vibhor.julka@l-3Com.com
Tom McMillan
L3 Communications, Linkabit
9890 Towne Centre Drive
San Diego, CA 92121
EMail: tom.mcmillan@l-3com.com
Zhang, et al. Expires April 5, 2015 [Page 8]