A YANG Data Model for Resource Reservation Protocol (RSVP)Juniper Networksvbeeram@juniper.netJuniper Networkstsaad@juniper.netCisco Systems, Inc.rgandhi@cisco.comVolta Networksxufeng.liu.ietf@gmail.comIndividuali_bryskin@yahoo.comTEAS Working GroupInternet-DraftThis document defines a YANG data model for the configuration and management of
the RSVP protocol. The YANG data model covers the building blocks that may be
augmented by other RSVP extension data models such as RSVP Traffic-Engineering
(RSVP-TE). It is divided into two modules that cover the basic and extended
RSVP features.YANG and is a data modeling language that was
introduced to define the contents of a conceptual data store that allows
networked devices to be managed using NETCONF . YANG has proved
relevant beyond its initial confines, as bindings to other interfaces (e.g.
RESTCONF ) and encoding other than XML (e.g. JSON) are being defined.
Furthermore, YANG data models can be used as the basis of implementation for
other interfaces, such as CLI and programmatic APIs.This document defines a YANG data model for the configuration and management of
the RSVP protocol . The data model is divided into two modules:
a base and extended RSVP YANG modules. The RSVP base YANG ‘ietf-rsvp’ module covers the
data that is core to the function of the RSVP protocol and MUST be supported by
vendors that support RSVP protocol . The RSVP extended ‘ietf-rsvp-extended’
module covers the data that is optional, or provides ability to tune
RSVP protocol base functionality. The support for RSVP extended module
features by vendors is considered optional.The RSVP YANG model provides the building blocks needed to allow augmentation
by other models that extend the RSVP protocol– such as using RSVP extensions to
signal Label Switched Paths (LSPs) as defined in .The YANG module(s) defined in this document are compatible with the Network
Management Datastore Architecture (NMDA) .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.The terminology for describing YANG data models is found in .In this document, names of data nodes and other data model objects are prefixed
using the standard prefix associated with the corresponding YANG imported
modules, as shown in .PrefixYANG moduleReferenceifietf-interfacesrtietf-routingrt-typesietf-routing-typesinetietf-inet-typesyangietf-yang-typeskey-chainietf-key-chainA full tree diagram of the module(s) defined in this document is given in
subsequent sections as per the syntax defined in .The RSVP YANG module augments the “control-plane-protocol” entry from the
‘ietf-routing’ module defined in . It also defines the identity
“rsvp” of base type “rt:routing-protocol” to identify the RSVP routing protocol.The ‘ietf-rsvp’ model defines a single instance of the RSVP protocol. The top
‘rsvp’ container encompases data for one such RSVP protocol instance. Multiple
instances can be defined as multiple control-plane protocols instances as
described in .The YANG data model defined has the common building blocks for the operation of
the base RSVP protocol for the session type defined in . The
augmentation of this model by other models (e.g. to support RSVP Traffic
Engineering (TE) extensions for signaling Label Switched Paths (LSPs)) are
outside the scope of this document and are discussed in separate document(s).This RSVP YANG data model defined in this document is divided into two modules: a base and extended
modules. The RSVP data covered in ‘ietf-rsvp’ module are categorized as core to
the function of the protocol and MUST be supported by vendors claiming the support for RSVP
protocol .The RSVP extended features that are covered in ‘ietf-rsvp-extended’ module are
categorized as either optional or providing ability to better tune the basic
functionality of the RSVP protocol. The support for RSVP extended features by
all vendors is considered optional.The relationship between the base and RSVP extended YANG modules and the IETF
routing YANG model is shown in .The RSVP data covered in the ‘ietf-rsvp’ YANG module provides the common building
blocks that are required to configure, operate and manage the RSVP protocol
and MUST be supported by vendors that claim the support for base RSVP protocol
defined in .In addition, the following standard RSVP core features are modeled under the
‘ietf-rsvp’ module:Basic operational statistics, including protocol messages, packets and errors.Basic RSVP authentication feature as defined in ) using string
based authentication key.Basic RSVP Refresh Reduction feature as defined in ().Basic RSVP Hellos feature as defined in ()Basic RSVP Graceful Restart feature as defined in , , and
.Optional features are beyond the basic configuration, and operation of the
RSVP protocol. The decision whether to support these RSVP features on a
particular device is left to the vendor that supports the RSVP core features.The following optional features that are covered in the ‘ietf-rsvp-extended’
YANG module:Advanced operational statistics, including protocol messages, packets and errors.Advanced RSVP authentication features as defined in ) using various
authentication key types including those defined in .Advanced RSVP Refresh Reduction features defined in ().Advanced RSVP Hellos features as defined in , and .Advanced RSVP Graceful Restart features as defined in , , and
.The RSVP YANG data model defines the ‘rsvp’ top-level container that contains
the configuration and operational state for the RSVP protocol.
The presence of this container enables the RSVP protocol functionality.The ‘rsvp’ top-level container also includes data that has router level scope
(i.e. applicable to all objects modeled under rsvp). It also contains
configuration and state data about the following types of RSVP objects:interfacesneighborssessionsThe derived state data is contained in “read-only” nodes directly under the
intended object as shown in .The following‘router-level’:The router-level scope configuration and state data are applicable to all
modeled objects under the top-level ‘rsvp’ container, and MAY affect the RSVP
protocol behavior.‘interfaces’:The ‘interfaces’ container includes a list of RSVP enabled interfaces. It
also includes RSVP configuration and state data that is applicable to all
interfaces. An entry in the interfaces list MAY carry its own configuration
or state data. Any data or state under the “interfaces” container level is
equally applicable to all interfaces unless it is explicitly overridden by
configuration or state under a specific interface.‘neighbors’ :The ‘neighbors’ container includes a list of RSVP neighbors. An entry in the
RSVP neighbor list MAY carry its own configuration and state relevant to the
specific RSVP neighbor. The RSVP neighbors can be dynamically discovered using
RSVP signaling, or can be explicitly configured.‘sessions’:The ‘sessions’ container includes a list RSVP sessions. An entry in the RSVP
session list MAY carry its own configuration and state relevant to a specific
RSVP session. RSVP sessions are usually derived state that are created as
result of signaling. This model defines attributes related to IP RSVP
sessions as defined in .The defined YANG data model supports configuration inheritance for neighbors, and
interfaces. Data nodes defined under the main container (e.g. the container
that encompasses the list of interfaces, or neighbors) are assumed to apply
equally to all elements of the list, unless overridden explicitly for a certain
element (e.g. interface).Modeling notifications data is key in any defined YANG data model. and
define a subscription and push mechanism for YANG datastores. This
mechanism currently allows the user to:Subscribe notifications on a per client basisSpecify subtree filters or XPath filters so that only interested
contents will be sent.Specify either periodic or on-demand notifications.The RSVP base module includes the core features and building blocks for modeling the RSVP
protocol as described in . shows the YANG tree representation for configuration, state
data and RPCs that are covered in ‘ietf-rsvp’ YANG module:The ietf-rsvp module imports from the following modules:ietf-interfaces defined in ietf-yang-types and ietf-inet-types defined in ietf-routing defined in ietf-key-chain defined in ietf-netconf-acm defined in This module also references the following documents:
, , , , , , and .The RSVP extended module augments the RSVP base module with optional feature data
as described in . shows the YANG tree representation for configuration and
state data that are covered in ‘ietf-rsvp-extended’ YANG module:The ‘ietf-rsvp-extended’ module imports from the following modules:ietf-rsvp defined in this documentietf-routing defined in ietf-yang-types and ietf-inet-types defined in ietf-key-chain defined in shows the RSVP extended YANG module:This module also references the following documents:
, , , , , and .This document registers the following URIs in the IETF XML registry
. Following the format in , the following registration
is requested to be made.This document registers two YANG modules in the YANG Module Names
registry .The YANG module specified in this document defines a schema for data that is
designed to be accessed via network management protocols such as NETCONF
or RESTCONF . The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Model (NACM) provides the
means to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol operations
and content.There are a number of data nodes defined in the YANG module(s) defined in this
document that are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., <edit-config>) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their sensitivity/vulnerability:/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/rsvp:rsvp/
/rsvp:globals
/rsvp:interfaces
/rsvp:sessionsAll of which are considered sensitive and if access to either of these is
compromised, it can result in temporary network outages or be employed to
mount DoS attacks.Some of the readable data nodes in this YANG module may be considered sensitive
or vulnerable in some network environments. It is thus important to control
read access (e.g., via get, get-config, or notification) to these data nodes.
These are the subtrees and data nodes and their sensitivity/vulnerability:/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/rsvp:rsvp/
/rsvp:globals
/rsvp:interfaces
/rsvp:sessionsAdditional information from these state data nodes can be inferred with respect
to the network topology, and device location and subsequently be used to mount
other attacks in the network.For RSVP authentication, the configuration supported is via the specification of
key-chains or the direct specification of key and authentication
algorithm, and hence security considerations of are inherited. This
includes the considerations with respect to the local storage and handling of
authentication keys.Some of the RPC operations defined in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. The RSVP YANG
module support the “clear-session” and “clear-neighbor” RPCs. If
access to either of these is compromised, they can result in
temporary network outages be employed to mount DoS attacks.The security considerations spelled out in the YANG 1.1 specification
apply for this document as well.The authors would like to thank Tom Petch for reviewing and providing useful
feedback about the document. The authors would also like to thank Lou Berger
for reviewing and providing valuable feedback on this document.A simple network setup is shown in {fig-example title}. R1 runs the RSVP routing
protocol on both interfaces ‘ge0/0/0/1’, and ‘ge0/0/0/2’.The instance data tree could then be as follows:Key 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.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.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).A YANG Data Model for Interface ManagementThis document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.This document obsoletes RFC 7223.A YANG Data Model for Routing Management (NMDA Version)This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.Common YANG Data Types for the Routing AreaThis document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.YANG Data Model for Key ChainsThis document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Subscription to YANG NotificationsThis document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.Subscription to YANG Notifications for Datastore UpdatesThis document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Resource ReSerVation Protocol (RSVP) -- Version 1 Functional SpecificationThis memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]RSVP-TE: Extensions to RSVP for LSP TunnelsThis 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]RSVP Cryptographic AuthenticationThis document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]RSVP Refresh Overhead Reduction ExtensionsThis document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful RestartThis document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.These extensions are not used to create or restore data plane state.The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart ProceduresThe Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification StatementUse of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]