OSPF Routing with Cross-Address Family Traffic Engineering TunnelsCisco Systems, Inc.De Kleetlaan 6aDiegem1831Belgiumas@cisco.comFuturewei Technologies, Inc.2330 Central ExpresswaySanta ClaraCA95050United States of Americaalvaro.retana@futurewei.commichael_barnes@usa.net
Routing
LSROSPFIPv4IPv6TEMPLSWhen using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
network, the Multiprotocol Label Switching (MPLS) TE Label Switched
Path (LSP) infrastructure may be duplicated, even if the destination
IPv4 and IPv6 addresses belong to the same remote router.
In order to
achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
computed over MPLS TE tunnels created using information propagated in
another OSPF instance. This issue is solved by advertising cross-address
family (X-AF) OSPF TE information.This document describes an update to RFC 5786 that allows for the easy
identification of a router's local X-AF IP addresses.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
.
Copyright Notice
Copyright (c) 2019 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
() 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
. Introduction
. Requirements Language
. Operation
. Backward Compatibility
. Automatically Switched Optical Networks
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionTE extensions to OSPFv2
and OSPFv3 have been
described to support intra-area
TE in IPv4 and IPv6 networks, respectively. In both cases, the TE
database provides a tight coupling between the routed protocol and
advertised TE signaling information. In other words, any use of the TE
database is limited to IPv4 for OSPFv2
and IPv6 for OSPFv3 .In a dual-stack network, it may be desirable to set up common MPLS TE
LSPs to carry traffic destined to addresses from different address
families on a router. The use of common LSPs eases potential scalability
and management concerns by halving the number of LSPs in the
network. Besides, it allows operators to group traffic based on
business characteristics, class of service, and/or applications;
the operators are not constrained by the network protocol used.
For example, an LSP created based on MPLS TE information propagated
by an OSPFv2 instance can be used to transport both IPv4 and IPv6
traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a
separate LSP for each address family. Even if, in some cases, the address-family-specific traffic is to be separated, calculation from a common TE
database may prove to be operationally beneficial.During the SPF calculation on the TE tunnel
head-end router, OSPF
computes shortcut routes using TE tunnels. A commonly used algorithm for
computing shortcuts is defined in . For that or
any similar algorithm to work with a common MPLS TE infrastructure in a
dual-stack network, a requirement is to reliably map the X-AF addresses
to the corresponding tail-end router. This mapping is a challenge
because the Link State Advertisements (LSAs) containing the routing
information are carried in one
OSPF instance, while the TE calculations may be done using a TE database
from a different OSPF instance.A simple solution to this problem is to rely on the Router ID to
identify a node in the corresponding OSPFv2 and OSPFv3 Link State
Databases (LSDBs). This solution would mandate both instances on the
same router to be configured with the same Router ID. However, relying
on the correctness of configuration puts additional burden and cost on
the operation of the network. The network becomes even more difficult to
manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example,
if area borders are chosen differently in the two protocols. Also, if
the routing processes do fall out of sync (e.g., having different Router
IDs for local administrative reasons), there is no defined way for other
routers to discover such misalignment and to take corrective measures
(such as to avoid routing traffic through affected TE tunnels or
alerting the network administrators). The use of misaligned Router IDs
may result in delivering the traffic to the wrong tail-end router, which
could lead to suboptimal routing or even traffic loops.This document describes an update to that
allows for the easy identification of a router's local X-AF IP
addresses. defined the Node IPv4 Local Address
and Node IPv6 Local Address sub-TLVs of the Node Attribute TLV for a
router to advertise additional local IPv4 and IPv6 addresses. However,
did not describe the advertisement and usage of
these sub-TLVs when the address family of the advertised local address
differed from the address family of the OSPF traffic engineering
protocol.This document updates so that a router can
also announce one or more local X-AF addresses using the corresponding
Local Address sub-TLV. Routers using the Node
Attribute TLV can include non-TE-enabled interface addresses in
their OSPF TE advertisements and also use the same sub-TLVs to carry
X-AF information, facilitating the mapping described above.The method specified in this document can also be used to compute the
X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of
a Point-to-Multipoint LSP . Considerations of
using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside
the scope of this document.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 when, and only when, they appear in all capitals,
as shown here.
OperationTo implement the X-AF routing technique described in this document,
OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3
will advertise the Node IPv4 Local Address sub-TLV, possibly in addition
to advertising other IP addresses as documented by .Multiple instances of OSPFv3 are needed if it is used for both IPv4
and IPv6 . The operation in this section is
described with OSPFv2 as the protocol used for IPv4; that is the most
common case. The case of OSPFv3 being used for IPv4 follows the same
procedure as what is indicated for OSPFv2 below.On a node that implements X-AF routing, each OSPF instance
advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for
OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that
can be used by the Constrained Shortest Path First (CSPF) to calculate MPLS TE LSPs:
The OSPF instance MUST advertise the IP address listed in the Router
Address TLV of
the X-AF instance maintaining the TE database.
The OSPF instance SHOULD include additional local addresses
advertised by the X-AF OSPF instance in its Node Local Address
sub-TLVs.
An implementation MAY advertise other local X-AF addresses.
When TE information is advertised in an OSPF instance, both natively
(i.e., as per RFC or )
and as X-AF Node Attribute TLV, it is left to local configuration to
determine which TE database is used to compute routes for the OSPF
instance.On Area Border Routers (ABRs), each advertised X-AF IP address MUST be
advertised into, at most, one area. If OSPFv2 and OSPFv3 ABRs coincide
(i.e., the areas for all OSPFv2 and OSPFv3 interfaces
are the same), then the X-AF addresses MUST be advertised into the same
area in both instances. This allows other ABRs connected to the same set
of areas to know with which area to associate computed MPLS TE
tunnels.During the X-AF routing calculation, X-AF IP addresses are used to
map locally created LSPs to tail-end routers in the
LSDB. The mapping algorithm can be described as:
Walk the list of all MPLS TE tunnels for which the computing
router is a head end. For each MPLS TE tunnel T:
If T's destination address is from the same address family as the
OSPF instance associated with the LSDB, then the extensions defined
in this document do not apply.
Otherwise, it is a X-AF MPLS TE tunnel. Note the tunnel's destination
IP address.
Walk the X-AF IP addresses in the LSDBs of all connected areas.
If a matching IP address is found, advertised by router R in area A,
then mark the tunnel T as belonging to area A and terminating on
tail-end router R. Assign the intra-area SPF cost to reach router R
within area A as the IGP cost of tunnel T.
After completing this calculation, each TE tunnel is associated with
an area and tail-end router in terms of the routing LSDB of the
computing OSPF instance and has a cost.The algorithm described above is to be used only if the Node Local
Address sub-TLV includes X-AF information.Note that, for clarity of description, the mapping algorithm is
specified as a single calculation. Implementations may choose to support equivalent mapping
functionality without implementing the algorithm as described.As an example, consider a router in a dual-stack network
using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing, respectively. Suppose the OSPFv2
instance is used to propagate MPLS TE information and the router is
configured to accept TE LSPs terminating at local addresses 198.51.100.1
and 198.51.100.2. The router advertises in OSPFv2 the IPv4 address
198.51.100.1 in the Router Address TLV, the additional local IPv4
address 198.51.100.2 in the Node IPv4 Local Address sub-TLV, and other
TE TLVs as required by . If the
OSPFv3 instance in the network is enabled for X-AF TE routing (that is,
to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the
OSPFv3 instance of the router will advertise the Node IPv4 Local Address
sub-TLV listing the local IPv4 addresses 198.51.100.1 and 198.51.100.2.
Other routers in the OSPFv3 network will use this information to
reliably identify this router as the egress LSR for MPLS TE LSPs
terminating at either 198.51.100.1 or 198.51.100.2.Backward CompatibilityOnly routers that serve as endpoints for one or more TE tunnels MUST
be upgraded to support the procedures described herein:
Tunnel tail-end routers advertise the Node IPv4 Local Address
sub-TLV and/or the Node IPv6 Local Address sub-TLV.
Tunnel head-end routers perform the X-AF routing calculation.
Both the endpoints MUST be upgraded before the tail end starts
advertising the X-AF information. Other routers in the network do not
need to support X-AF procedures.Automatically Switched Optical Networks updates
by
defining extensions to be used in an Automatically Switched Optical
Network (ASON). The Local TE Router ID sub-TLV is required for
determining ASON reachability. The implication is that if the Local TE
Router ID sub-TLV is present in the Node Attribute TLV, then the
procedures in apply, regardless of whether
any X-AF information is advertised.Security ConsiderationsThis document describes the use of the Local Address sub-TLVs to
provide X-AF information. The advertisement of these sub-TLVs, in any
OSPF instance, is not precluded by . As such, no
new security threats are introduced beyond the considerations in OSPFv2, OSPFv3,
and .The X-AF information is not used for SPF computation or normal
routing, so the mechanism specified here has no effect on IP routing.
However, generating incorrect information or tampering with the
sub-TLVs may have an effect on traffic engineering computations.
Specifically, TE traffic may be delivered to the wrong tail-end router,
which could lead to suboptimal routing, traffic loops, or exposing
the traffic to attacker inspection or modification. These threats are
already present in other TE-related specifications, and their
considerations apply here as well, including
and .IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Traffic Engineering (TE) Extensions to OSPF Version 2This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.Traffic Engineering Extensions to OSPF Version 3This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) ExtensionsOSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesOSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering TunnelsThis document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).There is no intent to specify solution-specific details or application-specific requirements in this document.The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]Support of Address Families in OSPFv3This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]Automatically Switched Optical Network (ASON) Routing for OSPFv2 ProtocolsThe ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]AcknowledgementsThe authors would like to thank Peter Psenak and Eric Osborne for
early discussions and Acee Lindem for discussing compatibility with ASON
extensions. Also, Eric Vyncke, Ben Kaduk, and Roman Danyliw provided
useful comments. We would also like to thank the authors of RFC 5786 for laying down
the foundation for this work.Authors' AddressesCisco Systems, Inc.De Kleetlaan 6aDiegem1831Belgiumas@cisco.comFuturewei Technologies, Inc.2330 Central ExpresswaySanta ClaraCA95050United States of Americaalvaro.retana@futurewei.commichael_barnes@usa.net