IGP Extensions for Scalable
Segment Routing based Enhanced VPNHuawei Technologiesjie.dong@huawei.comHuawei Technologieshuzhibo@huawei.comHuawei Technologieslizhenbin@huawei.comChina Unicomtangxy@chinaunicom.cnChina Unicompangran@chinaunicom.cnUniversity of Surreystewart.bryant@gmail.comLSR Working GroupEnhanced VPN (VPN+) aims to provide enhanced VPN services to support
some application's needs of enhanced isolation and stringent performance
requirements. VPN+ requires integration between the overlay VPN
connectivity and the characteristics provided by the underlay network. A
Virtual Transport Network (VTN) is a virtual underlay network which has
a customized network topology and a set of network resources allocated
from the physical network. A VTN could be used to support one or a group
of VPN+ services. In the context of network slicing, a VTN could be
instantiated as a network resource partition (NRP).This document specifies the IGP mechanisms with necessary extensions
to advertise the associated topology and resource attributes for
scalable Segment Routing (SR) based NRPs. Each NRP can have a customized
topology and a set of network resources allocated from the physical
network. Multiple NRPs may shared the same topology, and multiple NRPs
may share the same set of network resources on some network segments.
This allows flexible combination of the network topology and network
resource attributes to build a relatively large number of NRPs with a
relatively small number of logical topologies. A group of resource-aware
SIDs and SRv6 Locators can be assigned to each NRP. The proposed
mechanism is applicable to both Segment Routing with MPLS data plane
(SR-MPLS) and Segment Routing with IPv6 data plane (SRv6). This document
also describes the mechanism of using dedicated NRP ID in the data plane
instead of the per-NRP resource-aware SIDs and SRv6 Locators to further
reduce the control plane and data plane overhead of maintaining a large
number of NRPs.Enhanced VPN (VPN+) is an enhancement to VPN services to support the
needs of new applications, particularly the applications that are
associated with 5G services. These applications require enhanced
isolation and have more stringent performance requirements than that can
be provided with traditional overlay VPNs. These properties require
integration between the underlay and the overlay networks. specifies the framework of
enhanced VPN and describes the candidate component technologies in
different network planes and layers. An enhanced VPN can be used for 5G
network slicing, and will also be of use in more generic scenarios.To meet the requirement of different enhanced VPN services, a number
of virtual underlay networks need to be created, each with a customized
network topology and a set of network resources allocated from the
physical network to meet the requirement of one or a group of VPN+
services. Such a virtual underlay network is called Virtual Transport
Network (VTN) in . introduces the
concept Network Resource Partition (NRP) as a set of network resources
that are available to carry traffic and meet the SLOs and SLEs. In order
to allocate network resources to an NRP, the NRP is associated with a
network topology to define the set of links and nodes. Thus VTN and NRP
are similar concepts, and NRP can be seen as an instantiation of VTN in
the context of network slicing. For clarity, the rest of this document
uses NRP in the description of the proposed mechanisms and protocol
extensions. introduces
resource-aware segments by associating existing type of SIDs with
network resource attributes (e.g. bandwidth, processing or storage
resources). 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. describes the use
of resource-aware segments to build SR based NRPs. To allow the network
controller and network nodes to perform NRP-specific explicit path
computation and/or shortest path computation, the group of
resource-aware SIDs allocated by network nodes to each NRP and the
associated topology and resource attributes need to be distributed using
the control plane. analyzes the
scalability requirements and the control plane and data plane
scalability considerations of NRP. In order to support a relatively
large number of NRPs in the network, one proposed approach is to
separate the topology and resource attributes of the NRP in control
plane, so that the advertisement and processing of each type of
attribute could be decoupled. Multiple NRPs may shared the same
topology, and multiple NRPs may share the same set of network resources
on some network segments, while the difference in either the topology or
resource attributes makes them different NRPs. This allows flexible
combination of network topology and network resource attributes to build
a large number of NRPs with a relatively small number of logical
topologies.This document specifies the IGP control plane mechanisms with
necessary extensions for scalable SR based NRPs. A group of
resource-aware SIDs and SRv6 Locators can be assigned to each NRP. The
proposed mechanism is applicable to both segment routing with MPLS data
plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This
document also describes the mechanisms of using dedicated NRP ID in the
data plane instead of the per-NRP resource-aware SIDs to further reduce
the control plane and data plane overhead of maintaining a large number
of NRPs.In general this approach applies to both IS-IS and OSPF, while the
specific protocol extensions and encodings are different. In the current
version of this document, the required IS-IS extensions are described.
The required OSPF extensions will be described in a future version or in
a separate document.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.According to , an
NRP is a collection of network resources allocated in the underlay
network, and is associated with a network topology. Thus an NRP can be
defined as the combination of a set of network attributes, which include
the topology attribute, the resource attributes, and other possible
attributes.The IS-IS Network Resource Partition Definition (NRPD) sub-TLV is
used to advertise the definition of a NRP. It is a sub-TLV of the IS-IS
Router-Capability TLV 242 as defined in .The format of IS-IS NRPD sub-TLV is as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the included sub-TLVs.NRP ID: A domain significant 32-bit identifier which is used to
identify an NRP.MT-ID: 16-bit field which indicates the multi-topology identifier
as defined in . The first 4-bit are set to
zero.Algorithm: 8-bit identifier which indicates the algorithm which
applies to this NRP. It can be either a normal algorithm or a Flexible Algorithm .Flags: 8-bit flags. Currently all the flags are reserved for
future use. They SHOULD be set to zero on transmission and MUST be
ignored on receipt.Sub-sub-TLVs: optional sub-sub-TLVs to specify the additional
attributes of an NRP. Currently no sub-sub-TLV is defined in this
document.The NRPD Sub-TLV MAY be advertised in an LSP of any number. A
node MUST NOT advertise more than one NRPD Sub-TLV for a given NRP
ID.This section describes the mechanisms used to advertise the topology
attribute associated with SR based NRPs. Basically the topology of an
NRP can be determined by the MT-ID and/or the algorithm ID included in
the NRP definition. In practice, it could be described using two
optional approaches.The first approach is to use Multi-Topology Routing (MTR) with the segment routing
extensions to advertise the topology associated with the SR based NRPs.
Different algorithms MAY be used to further specify the computation
algorithm or the metric type used for path computation within the
topology. Multiple NRPs can be associated with the same <topology,
algorithm>, and the IGP computation with the <topology,
algorithm> tuple can be shared by these NRPs.The second approach is to use Flex-Algo to describe the topological
constraints of SR based NRPs on a shared network topology (e.g. the
default topology). Multiple NRPs can be associated with the same
Flex-Algo, and the IGP computation with this Flex-Algo can be shared by
these NRPs.Multi-Topology Routing (MTR) has been defined in and to create different
network topologies in one network. It also has the capability of
specifying customized attributes for each topology. The traditional
use cases of multi-topology are to maintain separate topologies for
unicast and multicast services, or to create different topologies for
IPv4 and IPv6 in a network. There are some limitations when MTR is
used with native IP forwarding, the considerations about MT based IP
forwarding are described in .MTR can be used with SR-MPLS data plane.
specifies the IS-IS extensions to support SR-MPLS data plane, in which
the Prefix-SID sub-TLVs can be carried in IS-IS TLV 235 (MT IP
Reachability) and TLV 237 (MT IPv6 IP Reachability), and the Adj-SID
sub-TLVs can be carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS
Neighbor Attribute).MTR can also be used with SRv6 data plane. specifies the IS-IS
extensions to support SRv6 data plane, in which the MT-ID is carried
in the SRv6 Locator TLV. The SRv6 End SIDs are carried as sub-TLVs in
the SRv6 Locator TLV, and inherit the topology/algorithm from the
parent locator. The SRv6 End.X SIDs are carried as sub-TLVs in the
IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute), and
inherit the topology/algorithm from the parent locator.These IGP extensions for SR-MPLS and SRv6 can be used to advertise
and build the topology for a group of SR based NRPs.An algorithm ID MAY be used to further specify the computation
algorithm or the metric type used for path computation within the
topology. specifies the mechanisms to
provide distributed computation of constraint-based paths, and how the
SR-MPLS prefix-SIDs and SRv6 locators can be used to steer packets
along the constraint-based paths.The Flex-Algo Definition (FAD) can be used to describe the
topological constraints for path computation on a network topology.
According to the network nodes' participation of a Flex-Algo, and the
rules of including or excluding specific Administrative Groups
(colors) and the Shared Risk Link Groups (SRLGs), the topology of an
NRP can be determined using the associated Flex-Algo on a particular
topology (e.g. the default topology).With the mechanisms defined in, prefix-SID advertisement can be
associated with a <topology, algorithm> tuple, in which the
algorithm can be a Flex-Algo. This allows network nodes to use the
prefix-SID to steer traffic along distributed computed paths according
to the identified Flex-Algo in the topology. specifies the
IS-IS extensions to support SRv6 data plane, in which the SRv6
locators advertisement can be associated with a specific topology and
a specific algorithm, which can be a Flex-Algo. With the mechanism
defined in , The SRv6 locator
can be used to steer traffic along distributed computed paths
according to the identified Flex-Algo in the topology. In addition,
topology/algorithm specific SRv6 End SID and End.X SID can be used to
enforce traffic over the LFA computed backup path.Multiple Flex-Algos MAY be defined to describe the topological
constraints on a shared network topology (e.g. the default
topology).This section specifies the mechanisms to advertise the network
resource attributes associated with the NRPs. The mechanism of
advertising the link resources and attributes associated with NRPs is
described. The mechanism of advertising node resources and attributes
associated with NRPs are for further study. Two optional approaches are
described in the following sub-sections: the first option is the L2
Bundle based approach, the second option is to
extend IGP to advertise per-NRP link TE attributes.On a Layer-3 interface, each NRP can be allocated with a subset of
link resources (e.g. bandwidth). A subset of link resources may be
dedicated to an NRP, or may be shared by a group of NRPs. Each subset
of link resource can be represented as a virtual layer-2 member link
under the Layer-3 interface, and the Layer-3 interface is considered
as a virtual Layer-2 bundle. The Layer-3 interface may also be a
physical Layer 2 link bundle, in this case a subset of link resources
allocated to an NRP may be provided by one of the physical Layer-2
member links. describes the IS-IS extensions to
advertise the link attributes of the Layer 2 member links which
comprise a Layer 3 interface. Such mechanism can be extended to
advertise the attributes of each physical or virtual member links, and
its associated NRPs.A new flag "E" (Exclusive) is defined in the flag field of the
Parent L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV
(25).E flag: When the E flag is set, it indicates each member link under
the Parent L3 link are used exclusively for one or a specific group of
NRPs, and load sharing among the member links is not allowed. When the
E flag is clear, it indicates load balancing and sharing among the
member links are allowed.A new NRP IDs sub-TLV is carried under the L2 Bundle Attribute
Descriptors to describe the mapping relationship between the NRPs and
the virtual or physical member links. As one or more NRPs may use the
same set of link resource on a specific network segment, these NRP IDs
will be advertised under the same virtual or physical member link.The format of the NRP IDs Sub-TLV is as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the number of NRP IDs included.Flags: 16 bit flags. All the bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.NRP IDs: One or more 32-bit identifiers to identify the NRPs
this member link belongs to.Each physical or virtual member link MAY be associated with a
different group of NRPs. Thus each L2 Bundle Attribute Descriptor may
carry the link local identifier and attributes of only one Layer 2
member link. Multiple L2 Bundle Attribute Descriptors will be used to
carry the attributes and the associated NRP IDs of all the Layer 2
member links.The TE attributes of each virtual or physical member link, such as
the bandwidth attributes and the SR SIDs, can be advertised using the
mechanism as defined in .A Layer-3 interface can participate in multiple NRPs, each of which
is allocated with a subset of the forwarding resources of the
interface. For each NRP, the associated resources can be described
using per-NRP TE attributes. A new NRP-specific TE attribute sub-TLV
is defined to advertise the link attributes associated with an NRP.
This sub-TLV MAY be advertised as a sub-TLV of the following TLVs:The format of the sub-TLV is shown as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the length of the Sub-sub-TLVs field.Flags: 8-bit flags. All the 8 bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.Reserved: 8-bit field reserved for future use, SHOULD be set to
0 on transmission and MUST be ignored on receipt.NRP ID Sub-sub-TLV: contains one or more NRP IDs which is
associated with the same group of TE attributes.Other Sub-sub-TLVs: the TLVs which carry the TE attributes
associated with the NRPs.The format of the NRP ID sub-sub-TLV is shown as below:Where:Type: TBDLength: The length of the value field of the sub-sub-TLV. It is
the number of the NRP IDs in the TLV multiplied by 4.NRP ID: A 32-bit identifier which is used to identify an
NRP.One sub-sub-TLV "NRP bandwidth sub-sub-TLV" is defined in this
document. Its format is shown as below:Where:Type: TBDLength: The length of the value field of the sub-sub-TLV. It is
set to 6.Flags: 8-bit flags. All the 8 bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.Reserved: 8-bit field reserved for future use, SHOULD be set to
0 on transmission and MUST be ignored on receipt.Bandwidth: The bandwidth allocated to the NRP, encoded in 32
bits in IEEE floating point format.The NRP Bandwidth sub-sub-TLV is optional. This sub-sub-TLV
SHOULD appear once at most in each NRP-specific TE attribute
sub-TLV.In order to steer packets to the NRP-specific paths which are
computed taking the topology and network resources of the NRP as the
constraints, some fields in the data packet needs to be used to infer or
identify the NRP the packet belongs to. As multiple NRPs may share the
same topology or Flex-Algo, the topology/Flex-Algo specific SR SIDs or
Locators cannot be used to distinguish the packets which belong to
different NRPs. Some additional data plane identifiers would be needed
to identify the NRP a packet belongs to.This section describes the mechanisms to advertise the NRP
identifiers in different data plane encapsulations.With SR-MPLS data plane, the NRP identification information can be
implicitly carried in the NRP-specific SIDs. Each node SHOULD allocate
a unique Prefix-SID for each NRP it participates in. On a Layer-3
interface, if each Layer 2 member link is associated with only one
NRP, the adj-SIDs of the L2 member links could also identify the NRPs.
If a member link is associated with multiple NRPs, NRP-specific
adj-SIDs MAY need to be allocated to help the NRP-specific local
protection.A new NRP-specific prefix-SID sub-TLV is defined to advertise the
prefix-SID and its associated NRP. This sub-TLV MAY be advertised as a
sub-TLV of the following TLVs:The format of the sub-TLV is shown as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the length of the SID/Index/Label field.Flags: 16-bit flags. The high-order 8 bits are the same as in
the Prefix-SID sub-TLV defined in . The
lower-order 8 bits are reserved for future use, which SHOULD be
set to 0 on transmission and MUST be ignored on receipt.NRP ID: A 32-bit identifier to identify the NRP this prefix-SID
associates with.SID/Index/Label: The same as defined in .One or more of NRP-specific Prefix-SID sub-TLVs MAY be
carried in the Multi-topology IP Reachability TLVs (TLV 235 or TLV
237), the MT-ID of the TLV SHOULD be the same as the MT-ID in the
definition of these NRPs.A new NRP-specific Adj-SID sub-TLV is defined to advertise the
adj-SID and its associated NRP. This sub-TLV may be advertised as a
sub-TLV of the following TLVs:The format of the sub-TLV is shown as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the length of the SID/Index/Label field.Flags: 16-bit flags. The high-order 8 bits are the same as in
the Adj-SID sub-TLV defined in . The
lower-order 8 bits are reserved for future use, which SHOULD be
set to 0 on transmission and MUST be ignored on receipt.NRP ID: A 32-bit global identifier to identify the NRP this
Adj-SID associates with.SID/Index/Label: The same as defined in .One or more NRP-specific Adj-SID sub-TLV MAY be carried in
the Multi-topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or
TLV 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the
definition of these NRPs.A new NRP-specific LAN Adj-SID sub-TLV is defined to advertise the
adj-SID and its associated NRP for each neighbor on a LAN interface.
This sub-TLV may be advertised as a sub-TLV of the following TLVs:The format of the sub-TLV is shown as below:Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the length of the SID/Index/Label field.Flags: 16-bit flags. The high-order 8 bits are the same as in
the Adj-SID sub-TLV defined in . The
lower-order 8 bits are reserved for future use, which SHOULD be
set to 0 on transmission and MUST be ignored on receipt.NRP ID: A 32-bit global identifier to identify the NRP this
Adj-SID associates with.Neighbor System-ID: IS-IS System-ID of length "ID Length" as
defined in [ISO10589].SID/Index/Label: The same as defined in .One or more NRP-specific LAN Adj-SID sub-TLV MAY be carried
in the Multi-topology ISN or Multi-topology IS Attribute TLVs (TLV 222
or TLV 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in
the definition of these NRPs.With SRv6 data plane, the NRP identification information can be
implicitly or explicitly carried in the SRv6 Locator of the
corresponding NRP, this is to ensure that all network nodes
(including both the end nodes and the transit nodes) can identify
the NRP to which a packet belongs to. Network nodes SHOULD allocate
NRP-specific Locators for each NRP it participates in. The
NRP-specific Locators are used as the covering prefix of
NRP-specific SRv6 End SIDs, End.X SIDs and other types of SIDs.In one possible approach, each NRP-specific Locator is advertised
in a separate TLV called "NRP specific SRv6 Locator TLV". Its format
is shown as below:Where:Type: TBDThe semantics of the Length field, the R bits and the MT ID
field are the same as those defined in .Followed by one or more locator entries of the form: Where:NRP ID: A 32-bit identifier to identify the NRP this Locator
is associated with.All the other fields are the same as those defined in .The NRP-specific SRv6 End SIDs are carried in the NRP-specific
SRv6 Locator TLV, and inherits the topology, algorithm and NRP from
the parent NRP-specific Locator.In another possible approach, when a group of NRPs share the same
topology/algorithm, the topology/algorithm specific Locator is the
covering prefix of a group of NRP-specific Locators. Then the
advertisement of NRP-specific locators can be optimized to reduce
the amount of Locator TLVs advertised in the control plane.A new NRP locator-block sub-TLV under the SRv6 Locator TLV is
defined to advertise a set of sub-blocks which follows the
topology/algorithm specific Locator. Each NRP locator-block value is
assigned to one of the NRPs which share the same
topology/algorithm.Where:Type: TBDLength: The length of the value field of the sub-TLV. It is
variable dependent on the number of NRPs and the Block
Length.Number of NRPs: The number of NRPs which share the same
topology/algorithm specific Locator as the covering prefix.Block Length: The length of the NRP locator-block which
follows the length of the topology/algorithm specific
Locator.NRP ID: A 32-bit identifier to identify the NRP the
locator-block is associates with.Block Value: The value of the NRP locator-block for each
NRP.With the NRP locator-block sub-TLV, the NRP-specific Locator can
be obtained by concatenating the topology/algorithm specific locator
and the locator-block value advertised for the NRP.The NRP-specific SRv6 End SIDs inherit the topology, algorithm
and the NRP from the parent NRP-specific Locator.The SRv6 End.X SIDs are advertised as sub-TLVs of TLV 22, 23, 25,
141, 222, and 223. In order to distinguish the End.X SIDs which
belong to different NRPs, a new "NRP ID sub-sub-TLV" is introduced
under the SRv6 End.X SID sub-TLV and SRv6 LAN End.X SID sub-TLV
defined in . Its
format is shown as below:Where:Type: TBD.Length: the length of the Value field of the TLV. It is set
to 4.NRP ID: A 32-bit identifier to identify the NRP this End.X
SID associates with.As the number of NRPs increases, with the mechanism described in
, the number of SR
SIDs and SRv6 Locators allocated for different NRPs would also
increase. In network scenarios where the number of SIDs or Locators
becomes a concern, some data plane optimization may be needed to
reduce the amount of SR SIDs and Locators allocated. As described in
, one approach is to
decouple the data plane identifiers used for topology based forwarding
and the identifiers used for the NRP-specific processing. Thus a
dedicated data plane NRP ID could be encapsulated in the packet. One
possible encapsulation of NRP ID in IPv6 data plane is proposed in
. One possible
encapsulation of NRP ID in MPLS data plane is proposed in .In that case, the NRP ID encapsulated in data plane can have the
same value as the NRP ID in control plane, so that the overhead of
advertising the mapping between the control plane NRP IDs and the
corresponding data plane identifiers could be saved.This document introduces no additional security vulnerabilities to
IS-IS.The mechanism proposed in this document is subject to the same
vulnerabilities as any other protocol that relies on IGPs.IANA is requested to assign a new code point in the "sub-TLVs for TLV
242 registry".IANA is requested to assign four new code points in the "sub-TLVs for
TLVs 22, 23, 25, 141, 222, and 223 registry".IANA is requested to assign two new code points in the "Sub-TLVs for
TLVs 27, 135, 235, 236 and 237 registry".IANA is requested to assign a new code point in the "IS-IS TLV
Codepoints registry".IANA is requested to assign a new code point in the "sub-sub-TLVs for
SRv6 End SID and SRv6 End.X SID registry".TBDThe authors would like to thank Mach Chen, Dean Cheng, Lee JooHeon,
Hongjie Yang and Guoqi Xu for their review and discussion of this
document.