Introducing Resource Awareness
to SR Segments
Huawei Technologies
jie.dong@huawei.com
Futurewei Technologies
stewart.bryant@gmail.com
KDDI Corporation
ta-miyasaka@kddi.com
China Telecom
zhuyq8@chinatelecom.cn
China Mobile
qinfengwei@chinamobile.com
China Mobile
li_zhenqiang@hotmail.com
Cisco Systems
fclad@cisco.com
SPRING Working Group
This document describes the mechanism to associate network resource
attributes to Segment Routing Identifiers (SIDs). Such SIDs are referred
to as resource-aware SIDs in this document. The resource-aware SIDs
retain their original forwarding semantics, but with the additional
semantics to identify the set of network resources available for the
packet processing action. The resource-aware SIDs can therefore be used
to build SR paths or virtual networks with a set of reserved network
resources. The proposed mechanism is applicable to both segment routing
with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane
(SRv6).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Segment Routing (SR) specifies a mechanism
to steer packets through an ordered list of segments. A segment is
referred to by its Segment Identifier (SID). With SR, explicit source
routing can be achieved without introducing per-path state into the
network. Compared with RSVP-TE , currently SR
does not have the capability of reserving network resources or
identifying a set of network resources reserved for individual services
or customers. Although a centralized controller can have a global view
of network state and can provision different services using different SR
paths, in data packet forwarding it still relies on traditional DiffServ
QoS mechanism to
provide coarse-grained traffic differentiation in the network. While
such kind of mechanism may be sufficient for some types of services,
some customers or services may require a set of dedicated network
resources to be allocated in the network to achieve resource isolation
from other customers/services in the same network. Also note the number
of such customers or services can be larger than the number of traffic
classes available with DiffServ QoS.
This document extends the SR paradigm without the need of defining
new SID types by associating SIDs with network resource attributes.
These resource-aware SIDs retain their original functionality, with the
additional semantics of identifying the set of network resources
available for the packet processing action. One typical type of the
network resource is bandwidth, but it is also possible to associate SR
SIDs with other types of resources (e.g., processing or storage
resources). On a particular network segment, multiple resource-aware
SIDs can be allocated, each of which represents a subset of network
resources allocated in the network to meet the requirement of individual
customers or services. The allocation of network resources on network
segments can be done either via local configuration or via a centralized
controller. Other approaches are possible such as use of a control
protocol signaling, but they are for further study. Each set of network
resources can be associated with one or multiple resource-aware SIDs.
These resource-aware SIDs can be used to build SR paths with a set of
reserved network resources, which can be used to carry service traffic
which requires dedicated network resources. The resource-aware SIDs can
also be used to build SR based virtual networks with the required
network topology and resource attributes. The proposed mechanism is
applicable to SR with both MPLS data plane (SR-MPLS) and IPv6 data plane
(SRv6).
In segment routing architecture , several
types of segments are defined to represent either topological or service
instructions. A topological segment can be a node segment or an
adjacency segment. A service segment may be associated with specific
service functions for service chaining purpose. This document introduces
additional resource semantics to these existing types of SIDs, so that
the SIDs can be used to identify the topology or service functions, and
also the set of network resources allocated on the network segments for
packet processing.
This section describes the mechanisms of using SR SIDs to identify
the additional resource information associated with SR paths or virtual
networks based on the two SR data plane instantiations: SR-MPLS and
SRv6. The mechanisms to identify the forwarding path or network topology
with SIDs as defined in can be reused, and the
control plane can be based on , and .
As specified in , an IGP Adjacency Segment
(Adj-SID) is an SR segment attached to a unidirectional adjacency or a
set of unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID)
is an SR segment attached to an IGP prefix, which identifies an
instruction to forward the packet along the path computed using the
routing algorithm in the associated topology. An IGP node segment is
an IGP-Prefix segment that identifies a specific router (e.g., a
loopback). As described in and , BGP PeerAdj SID is
used as an instruction to steer over a local interface towards a
specific peer node in a peering Autonomous System (AS). These types of
SIDs can be extended to represent both topological instructions and
the set of network resources allocated for packet processing following
the instruction. The MPLS instantiation of Segment Routing is
specified in .
For one IGP link, multiple resource-aware Adj-SIDs SHOULD be
allocated, each of which is associated with a subset of the link
resources allocated on the link, e.g. the link bandwidth. For one
inter-domain link, multiple BGP PeerAdj SIDs SHOULD be allocated, each
of which is associated with a subset of the link resources allocated
on the inter-domain link. The resource-aware Adj-SIDs MAY be
associated with a specific network topology and/or algorithm, so that
it is used only for resource-aware SR paths computed within the
topology and/or algorithm. Note that this per-segment resource
allocation complies to the SR paradigm, which avoids introducing
per-path state into the network. Several approaches can be used to
partition the link resource, such as , Layer-2
logical sub-interfaces, dedicated queues, etc. The detailed mechanism
of link resource partitioning is out of scope of this document.
For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be
allocated. A resource-aware prefix SID is associated with a network
topology and/or algorithm in which the attached node participates, and
in addition, each resource-aware prefix-SID is associated with a set
of local resources (e.g. bandwidth, processing and storage resources)
on each node participating in the same topology and/or algorithm. Such
set of network resources are used for forwarding the packets with this
resource-aware prefix-SID, along the path computed with the associated
topology and/or algorithm.
Although each resource-aware prefix-SID can be associated with a
set of dedicated resources, this implies additional overhead with
per-prefix resource reservation in both control plane signaling and
data plane states, and it is likely some resources will be wasted with
per-prefix resource allocation along all the possible paths. Thus it
is RECOMMENDED that a group of resource-aware prefix-SIDs be
associated with an aggregated set of network resources in the network.
This helps to reduce the dynamics in resource allocation, so that the
resource can be allocated based on network planning and does not have
to rely on dynamic signaling.
For one IGP prefix, each resource-aware prefix-SID can be
associated with a unique <topology, algorithm> tuple, in this
case different <topology, algorithm> tuples can be used to
distinguish the resource-aware prefix-SIDs for the same prefix. In
another case, for one IGP prefix, multiple resource-aware prefix-SIDs
can be associated with the same <topology, algorithm> tuple,
then an additional distinguisher needs to be introduced to distinguish
different resource-aware prefix-SIDs associated with the same topology
and algorithm but different groups of network resources. More details
about the new distinguisher will be described in a future version.
A group of resource-aware SR-MPLS SIDs can be used to construct SID
lists to steer the traffic along the explicit paths (either strict or
loose) and be processed using the set of network resources identified
by the SIDs.
In data packet forwarding, each resource-aware Adj-SID identifies
both the next-hop and the set of resources used for packet processing
on the outgoing interface. Each resource-aware Prefix-SID identifies a
path to the node which the prefix is attached to, and the set of
network resources used for packet forwarding on network nodes along
the path. The transit nodes determine the next-hop of the packet and
the set of associated local resources based on the resource-aware
prefix-SID, then forward the packet to the next-hop using the set of
local resources.
When the set of network resources allocated on the egress node also
needs to be determined, It is RECOMMENDED that Penultimate Hop Popping
(PHP) be disabled, or the inner service label
is used to infer the set of resources to be used for packet processing
on the egress node of the SR path.
This mechanism requires to allocate additional prefix-SIDs or
adj-SIDs for network segments to identify different set of network
resources. As the number of resource groups increases, the number of
SIDs would increase accordingly, while it should be noted that there
is no per-path state introduced into the network.
As specified in , an SRv6 Segment
Identifier (SID) is a 128-bit value which consists of a locator (LOC)
and a function (FUNCT), optionally it may also contain additional
arguments (ARG) immediately after the FUNCT. The Locator part of the
SID is routable and leads to the node which instantiates that SID,
which means the Locator can be parsed by all nodes in the network. The
FUNCT part of the SID is an opaque identification of a local function
bound to the SID, and the ARG bits of the SID can be used to encode
additional information for the processing of the behavoir bound to the
SID. The FUNCT and ARG parts can only be parsed by the node which
instantiates the SRv6 SID.
For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be
allocated. A resource-aware LOC is associated with a network topology
and/or algorithm in which the node participates, and in addition, a
resource-aware LOC is associated with a set of local resources (e.g.
bandwidth, processing and storage resources) on each node
participating in the same topology and/or algorithm. Such set of
network resources are used to forward the packets with SIDs which has
the resource-aware LOC as its prefix, along the path computed with the
associated topology and/or algorithm. Similar to the resource-aware
prefix-SIDs in SR-MPLS, the network resources used for the forwarding
instruction of a group of LOCs can be aggregated, this helps to reduce
the dynamics of resource allocation, so that the resource can be
allocated based on network planning and does not have to rely on
dynamic signaling.
For one IGP link, the resource-aware SRv6 End.X SIDs are used to
identify different set of link resources allocated. Each
resource-aware End.X SID SHOULD use a resource-aware LOC as its
prefix. SRv6 SIDs for other types of functions MAY also be assigned as
resource-aware SIDs, which can identify the set of network resources
allocated by the node for executing the function.
A group of resource-aware SRv6 SIDs can be used to construct SID
lists to steer the traffic along the explicit paths (either strict or
loose) and be processed using the set of network resources identified
by the SRv6 SIDs and Locators.
In data packet forwarding, each resource-aware End.X SID identifies
both the next-hop and the set of resources used for packet processing
on the outgoing interface. Each resource-aware Locator identifies the
path to the node which the LOC is assigned to, and the set of network
resources used for packet forwarding on network nodes along the path.
The transit nodes determine the next-hop of the packet and the set of
associated local resources based on the resource-aware Locator, then
forward the packet to the next-hop using the set of local
resources.
This mechanism requires to allocate additional SRv6 Locators and
SIDs for network segments to identify different set of network
resources. As the number of resource groups increases, the number of
SRv6 Locators and SIDs would increase accordingly, while it should be
noted that there is no per-path state introduced into the network.
The mechanism described in this document makes use of a centralized
controller to collect the information about the network (configuration,
state, routing databases, etc.) as well as the service information
(traffic matrix, performance statistics, etc.) for the planning of
network resources based on service requirement. Then the centralized
controller instructs network nodes to allocate the network resources and
associate the resources with resource-aware SIDs. The resource-aware
SIDs can be either explicitly provisioned by the controller, or
dynamically allocated by network nodes then reported to the controller.
The controller is also responsible for the centralized computation and
optimization of the SR paths with the topology, algorithm and network
resource constraints. The interaction between the controller and the
network nodes can be based on PCEP ,
Netconf/YANG and
BGP-LS . In some scenarios, extensions to some
of these protocols is needed, which are out of the scope of this
document and will be specified in separate documents. In some cases, a
centralized controller may not be used, but this would complicate the
operations and planning therefore not suggested.
The distributed control plane is complementary to the centralized
controller. A distributed control plane can be used for the collection
and distribution of the network topology and resource information
associated with SIDs among network nodes, then some of the nodes can
distribute the collected information to the centralized controller.
Distributed route computation for services with topology and resource
constraints may also be needed. The distributed control plane may be
based on , , or the combination of some of them
with necessary extensions. The details are out of the scope of this
document.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
The security considerations of segment routing are applicable to this
document.
The Resource-aware SIDs may be used for provisioning of SR paths or
virtual networks to carry traffic with latency as one of the SLA
parameters. By disrupting the latency of such traffic an attack can be
directly targeted at the customer application, or can be targeted at the
network operator by causing them to violate their SLA, triggering
commercial consequences. Dynamic attacks of this sort are not something
that networks have traditionally guarded against, and networking
techniques need to be developed to defend against this type of attack.
By rigorously policing ingress traffic and carefully provisioning the
resources provided to such services, this type of attack can be
prevented. However care needs to be taken when providing shared
resources, and when the network needs to be reconfigured as part of
ongoing maintenance or in response to a failure.
The details of the underlay network MUST NOT be exposed to third
parties, to prevent attacks aimed at exploiting a shared resource.
The authors would like to thank Mach Chen, Stefano Previdi, Charlie
Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and Joel
Halpern for the valuable discussion and suggestions to this
document.
Flex Ethernet Implementation Agreement