]> HPE

Sunnyvale California 94089 United States of America kireeti.ietf@gmail.com

Routing LSR WG multipath, traffic engineering, node capabilities Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of an MPTE tunnel. Multicast TE (MCTE) offers a more efficient approach to traffic engineering for multicast traffic. Again, an important node characteristic is whether a given node supports MCTE, i.e., whether it can participate in the provisioning and maintenance of an MCTE tunnel. This memo shows how these capabilities can be distributed in the IGP via Link State Routing TE Capabilities.

Introduction introduces the notion of multipath traffic engineering (MPTE). It describes how an entity (MPTE DAG computer or MC) can compute a directed acyclic graph (DAG) from one or more ingress nodes to one or more egress nodes that meets given traffic engineering (TE) constraints. The MC (usually one of the ingresses, or a path computation engine) will need information about the network to do the computation, most of which is available in IGP TE extensions. Once the computation is done, the MC communicates the result to the signaling source (SS) which then signals (or provisions) the MPTE tunnel via one of the following protocols: RSVP-TE , PCEP or BGP . One key piece of information that is not currently in the IGP extensions is whether or not a given node supports MPTE, i.e., is capable of sending and receiving MPTE updates that create and maintain the tunnel. An MPTE tunnel cannot be setup through such a node, and thus the MC has to take this into account. Similarly, proposes a new, more efficient approach to multicast traffic engineering (MCTE). There again, the MC would need to know if a given node can participate in an MCTE DAG. This memo fills this gap.

Terminology 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. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

Definition of Commonly Used Terms This section provides definitions for terms and abbreviations that have a specific meaning to the MPTE protocol and that are used throughout this memo.

constraints:

desired properties of paths between ingresses and egresses.

directed acyclic graph:

a directed graph that has no cycles.

directed graph (DAG):

a set of nodes and directed links. A network is represented by a directed graph.

egress:

an end node of an MPTE DAG.

ingress:

a starting node of an MPTE DAG.

MCTE:

multicast TE with constraints that creates a multicast tree from an ingress to one or more egresses.

MCTED:

an MCTE DAG; the result of computation on MCTE constraints.

MPTE:

multipath TE with constraints that uses multiple paths from one or more ingresses to one or more egresses.

MPTED:

an MPTE DAG; the result of computation on MPTE constraints.

MCTED/MPTED computer (MC):

the entity computing the MCTED or MPTED, typically the ingress (if there is a single ingress) or a Path Computation Element

node:

a vertex of a graph. A node may have associated attributes.

PCEP: Path Computation Element communication protocol.

signaling source (SS):

the initiator of MPTE signaling to establish, update or destroy an MPTE tunnel.

TE:

traffic engineering

MCTE/MPTE Capabilities describes IGP protocol extension for the discovery of the TE capabilities of a node. This memo extends that with six new capabilities:

MPTE Capabilities MPR bit: when set, this flag indicates that the node can process MPTE RSVP-TE messages. MPP bit: when set, this flag indicates that the node can process MPTE PCEP messages. MPB bit: when set, this flag indicates that the node can process MPTE BGP messages.

MCTE Capabilities MCR bit: when set, this flag indicates that the node can process MCTE RSVP-TE messages. MCP bit: when set, this flag indicates that the node can process MCTE PCEP messages. MCB bit: when set, this flag indicates that the node can process MCTE BGP messages. These bits are encoded in the TE Node Capability Descriptor defined in . This Descriptor is carried in ISIS and OSPF as defined in the same RFC.

IANA Considerations IANA is asked to allocate six bits for the above capabilities in the Link State Routing TE Capabilities registry.

Security Considerations This document specifies the content of the TE Node Capability Descriptor TLV in IS-IS and OSPF to be used for MPLS-TE path computation. As this TLV is not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with this TLV may have an effect on Traffic Engineering computation. Mechanisms defined to secure IS-IS Link State PDUs , OSPF LSAs , and their TLVs can be used to secure this TLV as well.

HPE Verizon Cox Communications Arrcus, Inc. Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, allowing for some "slack" to admit more paths. The load balancing at each hop is optimally weighted to each next hop rather than always being equally weighted. Moreover, traffic can enter and leave an MPTE construct via multiple ingresses and egresses. The proposal includes several choices of control and data planes. HPE Traffic Engineering (TE) offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. These benefits apply equally to unicast and multicast traffic. This memo proposes multicast traffic-engineering (MCTE), allowing the use of TE for multicast traffic. MCTE is an alternative proposal to point-to-multipoint TE specified in [RFC4875]. The approach in [RFC4875] creates a separate "sub-LSP" from the source to each leaf, resulting in a considerable amount of signaling and state in the network. MCTE, on the other hand, uses the junction approach proposed in MPTE [I-D.kompella-teas-mpte] to create the multicast tree with less signaling and state. [RFC4875] proposes the use of RSVP-TE for signaling and an MPLS data plane for carrying traffic. MCTE allows the use of several control and data planes to signal tunnels and carry traffic. In 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. RFC 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. It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK] This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community. This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.