Deterministic Networking (DetNet)
Controller Plane Framework
Independent
agmalis@gmail.com
Huawei
gengxuesong@huawei.com
Huawei
mach.chen@huawei.com
China Mobile
qinfengwei@chinamobile.com
Ericsson
balazs.a.varga@ericsson.com
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
+34 91624 6236
cjbc@it.uc3m.es
http://www.it.uc3m.es/cjbc/
This document provides a framework overview for the Deterministic
Networking (DetNet) controller plane. It discusses concepts and
requirements for DetNet controller plane which could be basis for future
solution specification.
Deterministic Networking (DetNet) provides the capability to carry
specified unicast and/or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency within a network
domain. As defined in , techniques used to
provide DetNet capability include reserving data plane resources for
individual (or aggregated) DetNet flows in some or all of the
intermediate nodes along the path of the flow, providing explicit routes
for DetNet flows that do not immediately change with the network
topology, and distributing data from DetNet flow packets over time
and/or space to ensure delivery of each packet’s data in spite of
the loss of a path.
DetNet data plane is defined in a set of documents that are anchored
by the DetNet Data Plane Framework (and the
associated DetNet MPLS defined in and DetNet IP
defined in and other data plane specifications
defined in , , , and )
While the Detnet Architecture and Data Plane documents are primarily
concerned with data plane operations, they do contain some requirements
for functions that would be required in order to automate DetNet service
provisioning and monitoring via a DetNet controller plane. The purpose
of this document is to gather these requirements into a single document
and discuss how various possible DetNet controller plane architectures
could be used to satisfy these requirements, while not providing the
protocol details for a DetNet controller plane solution. Such controller
plane protocol solutions will be the subject of subsequent
documents.
Note that in the DetNet overall architecture, the controller plane
includes what are more traditionally considered separate control and
management planes. Traditionally, the management plane is primarily
involved with fault management, configuration management and performance
management(sometimes accounting management and security management is
also considered in the management plane, but not in the scope of this
document). , while the control plane is primarily responsible for the
instantiation and maintenance of flows, MPLS label allocation and
distribution, and active in-band or out-of-band signaling to support
DetNet functions. In the DetNet architecture, all of this functionality
is combined into a single Controller Plane. See Section 4.4.2 of and the aggregation of Control and Management planes
in for further details.
This document uses the terminology established in the DetNet
Architecture , and the reader is assumed to be
familiar with that document and its 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.
Other DetNet documents, including [RFC8655] and , contain requirements for the Controller Plane. For
convenience, these requirements have been compiled here. These
requirements have been organized into 3 groups, including: requirements
primarily applicable to control plane, requirements primarily applicable
to management plane and requirements applicable to both planes.
The primary requirements for the DetNet Control Plane include:
Support the dynamic creation, modification, and deletion of
DetNet flows. This may include some or all of explicit path
determination, link bandwidth reservations, restricting flows to
specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN)
links), node buffer and other resource reservations, specification
of required queuing disciplines along the path, ability to manage
bidirectional flows, etc., as needed for a flow.
Support DetNet flow aggregation and de-aggregation via the
ability to dynamically create and delete flow aggregates (FAs),
and be able to modify existing FAs by adding or deleting
participating flows.
Allow flow instantiation requests to originate in an end
application (via an Application Programming Interface (API), via
static provisioning, or via a dynamic control plane, such as a
centralized SDN controller or distributed signaling protocols. See
for further discussion
of these options.
In the case of the DetNet MPLS data plane, manage DetNet
Service Label (S-Label), Forwarding Label (F-Label), and
Aggregation Label (A-Label) allocation
and distribution.
Also in the case of the DetNet MPLS data plane, support the
DetNet service sub-layer, which provides DetNet service functions
such as protection and reordering through the use of packet
replication, duplicate elimination, and packet ordering functions
(PREOF).
Support queue control techniques defined in Section 4.5 of
and that require time
synchronization among network nodes.
Advertise static and dynamic node and link resources such as
capabilities and adjacencies to other network nodes (for dynamic
signaling approaches) or to network controllers (for centralized
approaches).
Scale to handle the number of DetNet flows expected in a domain
(which may require per-flow signaling or provisioning).
Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the
location in the network and the DetNet functionality (e.g. transit
node vs. relay node).
The primary requirements of the DetNet Management Plane are that it
must be able to:
Monitor the performance of DetNet flows and nodes to ensure
that they are meeting required objectives, both proactively and
on-demand.
Support DetNet flow continuity check and connectivity
verification functions.
Support testing and monitoring of packet replication, duplicate
elimination, and packet ordering functionality in the DetNet
domain.
The following requirements apply to both the DetNet Controller and
Management Planes:
Operate in a converged network domain that contains both DetNet
and non-DetNet flows.
Adapt to DetNet domain topology changes such as links or nodes
failures (fault recovery/restoration), additions and removals.
As noted in the Introduction, the DetNet control plane is responsible
for the instantiation and maintenance of flows, allocation and
distribution of flow related information (e.g., MPLS label), and active
in-band or out-of-band information distribution to support these
functions.
The following sections define three types of DetNet control plane
architectures: a fully distributed control plane utilizing dynamic
signaling protocols, a fully centralized SDN-like control plane, and a
hybrid control plane containing both distributed protocols and
centralized controlling . This document describes the various
information exchanges between entities in the network for Each type of
these architectures and the corresponding advantages and
disadvantages.
In each of the following sections, there are examples to illustrate
possible mechanisms that could be used in each type of the
architectures. They are not meant to be exhaustive or to preclude any
other possible mechanism that could be used in place of those used in
the examples.
In a fully distributed configuration model, User-to-Network
Interface (UNI) information is transmitted over a DetNet UNI protocol
from the user side to the network side.Then UNI and network
configuration information propagate in the network via distributed
control plane signaling protocols. Such a DetNet UNI protocol is not
necessary in case that the End-systems are DetNet capable.
Taking an RSVP-TE MPLS network as an example, where end systems are
not part of the DetNet domain:
Network nodes collects topology information and DetNet
capabilities of the network nodes through IGP;
Ingress edge node receives a flow establishment request from
the UNI and calculates one or more valid path(s);
The ingress node sends a PATH message with an explicit route
through RSVP-TE . After receiving the PATH
message, the egress edge node sends a RESV message with the
distributed label and resource reservation request.
In this example, both IGP and RSVT-TE may request extensions
for DetNet.
In the fully SDN/centralized configuration model, flow/UNI
information is transmitted from a Centralized User Controller or from
applications via an API/ northbound interface to a Centralized
Controlle. Network node configurations for DetNet flows are performed
by the controller using a protocol such as NETCONF /YANG or PCE-CC .
Take the following case as an example::
A Centralized Controller collects topology information and
DetNet capabilities of the network nodes via NETCONF/YANG;
The Controller receives a flow establishment request from a UNI
and calculates one or more valid path(s) through the network;
The Controller chooses the optimal path and configures the
devices along that path for DetNet flow transmission via
PCE-CC.
Protocols in the above example may require extensions for
DetNet.
In the hybrid model, controller and control plane protocols work
together to provide DetNet services, and there are a number of
possible combinations.
In the following case, RSVP-TE and controller are used
together:
Controller collects topology information and DetNet
capabilities of the network nodes via an IGP and/or BGP-LS ;
Controller receives a flow establishment request through API
and calculates one or more valid path(s) through the network ;
Based on the calculation result, the Controller distributes
flow path information to the ingress edge node and configures
network nodes along the path with necessary DetNet information
(e.g. for replication/duplicate elimination)
Using RSVP-TE, the ingress edge node sends a PATH message with
an explicit route. After receiving the PATH message, the egress
edge node sends a RESV message with the distributed label and
resource reservation request.
There are many other variations that could be included in a hybrid
control plane. The requested DetNet extensions for protocol in each
possible case is for future work.
This section discusses requested control plane features for DetNet
mechanisms as defined in , including explicit
path, resource reservation, service protection(PREOF). Different DetNet
service may implement part/all of them based on the requirements.
Explicit paths are required in DetNet to provide a stable
forwarding service and guarantee that DetNet service is not impacted
when the network topology changes. The following features are
necessary in control plane to implement explicit paths in DetNet:
Path computation: DetNet explicit paths need to meet the SLA
(Service Level Agreement) requirements of the application, which
include bandwidth, maximum end- to-end delay, maximum end-to-end
delay variation, maximum loss ratio, etc. In a distributed network
system, IGP with CSPF (Constrained Shortest Path First) may be
used to compute a set of feasible paths for a DetNet service. In a
centralized network system, controller can compute paths
satisfying the requirements of DetNet based on the network
information collected from the DetNet domain.
Path establishment: The computed path for the DetNet service
has to be sent/configured/signaled to the network device, so the
corresponding DetNet flow could pass through the network domain
following the specified path.
DetNet flows are supposed to be protected from congestion, so
sufficient resource reservation for DetNet service could protect
service from congestion. There are multiple types of resources in the
network that could be allocated to DetNet flows, e.g., packet
processing resource, buffer resource, and bandwidth of the output
port. The network resource requested by a specified DetNet service is
determined by the SLA requirements and network capability.
Resource Allocation: Port bandwidth is one of the basic
attributes of a network device which is easy to obtain or
calculate. In current traffic engineering implementations, network
resource allocation is synonymous with bandwidth allocation. A
DetNet flow is characterized with a traffic specification as
defined in , including attributes such as
Interval, Maximum Packets Per Interval, and Maximum Payload Size.
The traffic specification describes the worst case, rather than
the average case, for the traffic, to ensure that sufficient
bandwidth and buffering resources are reserved to satisfy the
traffic specification. However, in case of DetNet, resource
allocation is more than simple bandwidth reservation. For example,
allocation of buffers and required queuing disciplines during
forwarding may be required as well. Furthermore, resources must be
ensured to execute DetNet service sub-layer functions on the node,
such as protection and reordering through the use of packet
replication, duplicate elimination, and packet ordering functions
(PREOF).
Device configuration with or without flow discrimination: The
resource allocation can be guaranteed by device configuration. For
example, an output port bandwidth reservation can be configured as
a parameter of queue management and the port scheduling algorithm.
When DetNet flows are aggregated, a group of DetNet flows share
the allocated resource in the network device. When the DetNet
flows are treated independently, the device should maintains a
mapping relationship between a DetNet flow and its corresponding
resources.
DetNet path redundancy is supported via packet replication,
duplicate elimination, and packet ordering functions (PREOF). A DetNet
flow is replicated and goes through multiple networks paths to avoid
packet loss caused by device or link failures. In general, current
control plane mechanisms that can be used to establish an explicit
path, whether distributed or centralized, support point-to-point (P2P)
and point-to-multipoint (P2MP) path establishment. PREOF requires the
ability to compute and establish a set of multiple paths (e.g.,
multiple LSP segments in an MPLS network) from the point(s) of packet
replication to the point(s) of packet merging and ordering. Mapping of
DetNet (member) flows to explicit path segments has to be ensured as
well. Protocol extensions will be required to support these new
features. Terminology will also be required to refer to this
coordinated set of path segments (such as an “LSP graph”
in case of DetNet MPLS data plane).
For the purposes of this document, “traditional MPLS”
is defined as MPLS without the use of segment routing (see for a discussion of MPLS with segment routing) or
MPLS-TP .
In traditional MPLS domains, a dynamic control plane using
distributed signaling protocols is typically used for the
distribution of MPLS labels used for forwarding MPLS packets. The
dynamic signaling protocols most commonly used for label
distribution are LDP , RSVP-TE, and BGP
(which enables BGP/MPLS-based Layer 3 VPNs
and Layer 2 VPNs ).
Any of these protocols could be used to distribute DetNet Service
Labels (S-Labels) and Aggregation Labels (A-Labels) . As discussed in ,
S-Labels are similar to other MPLS service labels, such as
pseudowire, L3 VPN, and L2 VPN labels, and could be distributed in a
similar manner, such as through the use of targeted LDP or BGP. If
these were to be used for DetNet, they would require extensions to
support DetNet-specific features such as PREOF, aggregation
(A-Labels), node resource allocation, and queue placement.
However, as discussed in , distributed signaling
protocols may have difficulty meeting DetNet’s scalability
requirements. MPLS also allows SDN-like centralized label management
and distribution as an alternative to distributed signaling
protocols, using protocols such as PCEP and OpenFlow .
PCEP, particularly when used as a part of PCE-CC, is a possible
candidate protocol to use for centralized management of traditional
MPLS-based DetNet domains. However, PCE path calculation algorithms
would need to be extended to include the location determination for
PREOF nodes in a path, and the means to signal the necessary
resource reservation and PREOF function placement information to
network nodes. See
((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for further
discussion of PCE-CC and PCEP for centralized control of an MPLS
domain.
For the purposes of this document, “traditional IP”
is defined as IP without the use of segment routing (see for a discussion of IP with segment routing). In a
later revision of this document, this section will discuss possible
protocol extensions to existing IP routing protocols such as OSPF,
IS-IS, and BGP. It should be noted that a DetNet IP data plane is simpler than a DetNet MPLS data plane , and doesn’t support PREOF, so only one
path per flow or flow aggregate is required.
Segment Routing is a scalable approach
to building network domains that provides explicit routing via
source routing encoded in packet headers and it is combined with
centralized network control to compute paths through the network.
Forwarding paths are distributed with associated policy to network
edge nodes for use in packet headers. As such, segment routing can
be considered as a new data plane for both MPLS and IP. It reduces
the amount of network signaling associated with distributed
signaling protocols such as RSVP-TE, and also reduces the amount of
state in core nodes compared with that required for traditional MPLS
and IP routing, as the state is now in the packets rather than in
the routers. This could be useful for DetNet, where a very large
number of flows through a network domain are expected, which would
otherwise require the instantiation of state for each flow
traversing each node in the network. However, further analysis is
needed on the expected gain, as DetNet flows may require various
type of DetNet specific resources as well.
In a later revision of this document, this section will discuss
the impact of DetNet on the Segment Routing Control and Management
planes. Note that the DetNet MPLS and IP data planes described in
and were
constructed to be compatible with both types of segment routing,
SR-MPLS and SRv6 . However, as of this
writing, traffic engineering and resource reservation for segment
routing are currently unsolved problems.
Editor’s note: this section may be collapsed to previous
sections and listing MPLS segment routing in the MPLS section as one
of the possible explicit routing techniques for MPLS, and do the
same for IP.
The Management Plane includes the ability to statically provision
network nodes and to use OAM to monitor DetNet performance and detect
outages or other issues at the DetNet layer.
Static provisioning in a Detnet network nodes will be performed via
the use of appropriate YANG models, including and .
This document covers the general considerations for OAM.
Active PM is performed by injecting OAM packets into the
network to estimate the performance of the network by measuring
the performance of the OAM packets. Adding extra traffic can
affect the delay and throughput performance of the network, and
for this reason active PM is not recommended for use in
operational DetNet domains. However, it is a useful test tool when
commissioning a new network or during troubleshooting.
Passive PM monitors the actual service traffic in a network
domain in order to measure its performance without having a
detrimental affect on the network. As compared to Active PM,
Passive PM is much preferred for use in DetNet domains.
The detailed requirements for connectivity and fault/defect
detection and management in DetNet IP domain and DetNet MPLS domain
are defined in respectively in and .
When there are multiple domains involved, one or multiple controller
plane function (CFP) would have to collaborate to implement the requests
received from the flow management entity (FME, as defined in
þRFC8655]) as per-flow, per-hop behaviors installed in the DetNet
nodes for each individual flow. Adding multi-domain support might
require some support at the CPF. For example, CPFs sitting at different
domains need to discover themselves, authenticate and negotiate per-hop
behaviors. Depending on the multi-domain support provided by the
application plane, the controller plane might berelieved from some
responsibilities (e.g., if the application plane is taking care of
splitting what needs to be provided by each domain).
If the case of RAW is considered, additional considerations for
communications among per-domain PCEs and/or PSEs would be required, as
these entities might not have the full visibility nor capability to act
on the other domains (e.g., there are no multi-domain OAM solutions in
place yet), limiting its capability to guarantee any given SLA.
In a later revision of this document, this section will contain a gap
analysis of existing IETF control and management plane protocols not
already discussed elsewhere in this document for their ability (or
inability) to satisfy the requirements in ,
and discuss possible protocol extensions to existing protocols to fill
the gaps, if any.
This document has no actions for IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Editor's note: This section needs more details.
The overall security considerations of DetNet are discussed in and . For
DetNet networks that make use of Segment Routing (whether SR-MPLS or
SRv6), the security considerations in also
apply.
DetNet networks that make use of a centralized controller plane may
be threatened by the loss of connectivity (whether accidental or
malicious) between the central controller and the network nodes, and/or
the spoofing of control messages from the controller to the network
nodes. This is important since such networks depend on centralized
controllers to calculate flow paths and instantiate flow state in the
network nodes. For networks that use both DetNet and Segment Routing
with a centralized controller, this would also include the calculation
of SID lists and their installation in edge/border routers.
In both cases, such threats may be mitigated through redundant
controllers, the use of authentication between the controller(s) and the
network nodes, and other mechanisms for protection against DOS attacks.
A mechanism for supporting one or more alternative central controllers
and the ability to fail over to such an alternative controller will be
required.
Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their
review comments.
Deterministic Networking Architecture
This document provides the overall architecture for
Deterministic Networking (DetNet), which provides a capability to
carry specified unicast or multicast data flows for real-time
applications with extremely low data loss rates and bounded
latency within a network domain. Techniques used include 1)
reserving data-plane resources for individual (or aggregated)
DetNet flows in some or all of the intermediate nodes along the
path of the flow, 2) providing explicit routes for DetNet flows
that do not immediately change with the network topology, and 3)
distributing data from DetNet flow packets over time and/or space
to ensure delivery of each packet's data in spite of the loss of a
path. DetNet operates at the IP layer and delivers service over
lower-layer technologies such as MPLS and Time- Sensitive
Networking (TSN) as defined by IEEE 802.1.
Software-Defined Networking (SDN): Layers and Architecture
Terminology
Software-Defined Networking (SDN) refers to a new approach for
network programmability, that is, the capacity to initialize,
control, change, and manage network behavior dynamically via open
interfaces. SDN emphasizes the role of software in running
networks through the introduction of an abstraction for the data
forwarding plane and, by doing so, separates it from the control
plane. This separation allows faster innovation cycles at both
planes as experience has already shown. However, there is
increasing confusion as to what exactly SDN is, what the layer
structure is in an SDN architecture, and how layers interface with
each other. This document, a product of the IRTF Software-Defined
Networking Research Group (SDNRG), addresses these questions and
provides a concise reference for the SDN research community based
on relevant peer-reviewed literature, the RFC series, and relevant
documents by other standards organizations.
Key words for use in RFCs to Indicate Requirement
Levels
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.
DetNet Flow Information Model
This document describes flow and service information model for
Deterministic Networking (DetNet). These models are defined for IP
and MPLS DetNet data planes
Segment Routing Architecture
Segment Routing (SR) leverages the source routing paradigm. A
node steers a packet through an ordered list of instructions,
called "segments". A segment can represent any instruction,
topological or service based. A segment can have a semantic local
to an SR node or global within an SR domain. SR provides a
mechanism that allows a flow to be restricted to a specific
topological path, while maintaining per-flow state only at the
ingress node(s) to the SR domain.
SR can be directly applied to the MPLS architecture with no
change to the forwarding plane. A segment is encoded as an MPLS
label. An ordered list of segments is encoded as a stack of
labels. The segment to process is on the top of the stack. Upon
completion of a segment, the related label is popped from the
stack.
SR can be applied to the IPv6 architecture, with a new type of
routing header. A segment is encoded as an IPv6 address. An
ordered list of segments is encoded as an ordered list of IPv6
addresses in the routing header. The active segment is indicated
by the Destination Address (DA) of the packet. The next active
segment is indicated by a pointer in the new routing header.
Deterministic Networking (DetNet) Security
Considerations
A DetNet (deterministic network) provides specific performance
guarantees to its data flows, such as extremely low data loss
rates and bounded latency. As a result, securing a DetNet implies
that in addition to the best practice security measures taken for
any mission-critical network, additional security measures may be
needed whose purpose is exclusively to secure the intended
operation of these novel service properties. Designers of DetNet
components (such as routers) that provide these unique DetNet
properties have the responsibility to uphold certain
security-related properties that can be assumed by DetNet system-
level designers. For example, the assumption that network traffic
associated with a given flow can never affect traffic associated
with a different flow is only true if the underlying components
make it so. This document addresses DetNet-specific security
considerations from the perspective of both the DetNet component
designer and the DetNet system-level designer. It is assumed that
both classes of reader are already familiar with network security
best practices for the data plane technologies underlying a given
DetNet implementation. Component-level considerations include
isolation of data flows from each other, ingress filtering, and
detection and reporting of packet arrival time violations.
System-level considerations include a threat model and a taxonomy
of relevant attacks, including their potential impacts and
mitigations. A given DetNet may require securing only certain
aspects of DetNet performance, for example extremely low data loss
rates but not necessarily bounded latency. Therefore this document
provides an association of threats against various use cases by
industry, and also against the individual service properties as
defined in the DetNet Use Cases. This document also addresses
common DetNet security considerations related to the IP and MPLS
data plane technologies (the first to be identified as supported
by DetNet), thereby complementing the Security Considerations
sections of the various DetNet Data Plane (and other) DetNet
documents.
OpenFlow Switch Specification, Version 1.5.1 (Protocol
version 0x06)
Open Networking Foundation
RSVP-TE: Extensions to RSVP for LSP Tunnels
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]
IEEE Standard for Local and metropolitan area networks --
Bridges and Bridged Networks - Amendment 25: Enhancements for
Scheduled Traffic
IEEE
Enhancements to the forwarding process that supports scheduled
traffic is provided in this amendment to IEEE Std 802.1Q-2014.
An Analysis of Scaling Issues in MPLS-TE Core
Networks
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is
deployed in providers' core networks. As providers plan to grow
these networks, they need to understand whether existing protocols
and implementations can support the network sizes that they are
planning.
This document presents an analysis of some of the scaling
concerns for the number of Label Switching Paths (LSPs) in MPLS-TE
core networks, and examines the value of two techniques (LSP
hierarchies and multipoint-to-point LSPs) for improving scaling.
The intention is to motivate the development of appropriate
deployment techniques and protocol extensions to enable the
application of MPLS-TE in large networks.
This document only considers the question of achieving
scalability for the support of point-to-point MPLS-TE LSPs.
Point-to-multipoint MPLS-TE LSPs are for future study. This memo
provides information for the Internet community.
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]
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]
An Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control
The Path Computation Element (PCE) is a core component of
Software- Defined Networking (SDN) systems. It can compute optimal
paths for traffic across a network and can also update the paths
to reflect changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths
(LSPs), which are supplied to the head end of the LSP using the
Path Computation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS
traffic-engineered (TE) networks, and the PCE may be used to
determine paths in a range of use cases including static LSPs,
segment routing, Service Function Chaining (SFC), and most forms
of a routed or switched network. It is, therefore, reasonable to
consider PCEP as a control protocol for use in these environments
to allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for
PCEP as a control protocol in this environment, and introduces the
implications for the protocol. A PCE-based central controller can
simplify the processing of a distributed control plane by blending
it with elements of SDN and without necessarily completely
replacing it.
This document does not describe use cases in detail and does
not define protocol extensions: that work is left for other
documents.
North-Bound Distribution of Link-State and Traffic
Engineering (TE) Information Using BGP
In a number of environments, a component external to a network
is called upon to perform computations based on the network
topology and current state of the connections within the network,
including Traffic Engineering (TE) information. This is
information typically distributed by IGP routing protocols within
the network.
This document describes a mechanism by which link-state and TE
information can be collected from networks and shared with
external components using the BGP routing protocol. This is
achieved using a new BGP Network Layer Reachability Information
(NLRI) encoding format. The mechanism is applicable to physical
and virtual IGP links. The mechanism described is subject to
policy control.
Applications of this technique include Application-Layer
Traffic Optimization (ALTO) servers and Path Computation Elements
(PCEs).
MPLS Transport Profile Data Plane Architecture
The Multiprotocol Label Switching Transport Profile (MPLS-TP)
is the set of MPLS protocol functions applicable to the
construction and operation of packet-switched transport networks.
This document specifies the subset of these functions that
comprises the MPLS-TP data plane: the architectural layer
concerned with the encapsulation and forwarding of packets within
an MPLS-TP network.
This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and Pseudowire
Emulation Edge-to-Edge (PWE3) architectures to support the
capabilities and functionalities of a packet transport network.
[STANDARDS-TRACK]
LDP Specification
The architecture for Multiprotocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two
Label Switching Routers (LSRs) must agree on the meaning of the
labels used to forward traffic between and through them. This
common understanding is achieved by using a set of procedures,
called a label distribution protocol, by which one LSR informs
another of label bindings it has made. This document defines a set
of such procedures called LDP (for Label Distribution Protocol) by
which LSRs distribute labels to support MPLS forwarding along
normally routed paths. [STANDARDS-TRACK]
Using BGP to Bind MPLS Labels to Address Prefixes
This document specifies a set of procedures for using BGP to
advertise that a specified router has bound a specified MPLS label
(or a specified sequence of MPLS labels organized as a contiguous
part of a label stack) to a specified address prefix. This can be
done by sending a BGP UPDATE message whose Network Layer
Reachability Information field contains both the prefix and the
MPLS label(s) and whose Next Hop field identifies the node at
which said prefix is bound to said label(s). This document
obsoletes RFC 3107.
BGP Communities for Data Collection
BGP communities (RFC 1997) are used by service providers for
many purposes, including tagging of customer, peer, and
geographically originated routes. Such tagging is typically used
to control the scope of redistribution of routes within a
provider's network and to its peers and customers. With the advent
of large-scale BGP data collection (and associated research), it
has become clear that the information carried in such communities
is essential for a deeper understanding of the global routing
system. This memo defines standard (outbound) communities and
their encodings for export to BGP route collectors. This document
specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for
improvements.
BGP MPLS-Based Ethernet VPN
This document describes procedures for BGP MPLS-based Ethernet
VPNs (EVPN). The procedures described here meet the requirements
specified in RFC 7209 -- "Requirements for Ethernet VPN
(EVPN)".
Segment Routing with the MPLS Data Plane
Segment Routing (SR) leverages the source-routing paradigm. A
node steers a packet through a controlled set of instructions,
called segments, by prepending the packet with an SR header. In
the MPLS data plane, the SR header is instantiated through a label
stack. This document specifies the forwarding behavior to allow
instantiating SR over the MPLS data plane (SR-MPLS).
IPv6 Segment Routing Header (SRH)
Segment Routing can be applied to the IPv6 data plane using a
new type of Routing Extension Header called the Segment Routing
Header. This document describes the Segment Routing Header and how
it is used by Segment Routing capable nodes.
Deterministic Networking (DetNet) Configuration YANG
Model
This document contains the specification for Deterministic
Networking flow configuration YANG Model. The model allows for
provisioning of end-to-end DetNet service along the path without
dependency on any signaling protocol. The YANG module defined in
this document conforms to the Network Management Datastore
Architecture (NMDA).
Deterministic Networking (DetNet) Topology YANG Model
This document defines a YANG data model for Deterministic
Networking (DetNet) topology discovery and capability
configuration. The YANG module defined in this document conforms
to the Network Management Datastore Architecture (NMDA).