SRv6 for Inter-Layer
Network ProgrammingChina MobileNo.32 XuanWuMen West StreetBeijing, 100053Chinahanliuyan@chinamobile.comHuawei TechnologiesHuawei Campus, No.156 Beiqing RoadBeijing, 100095Chinajie.dong@huawei.comChina MobileNo.32 XuanWuMen West StreetBeijing, 100053Chinaduzongpeng@foxmail.comChina MobileNo.32 XuanWuMen West StreetBeijing, 100053Chinawangminxue@chinamobile.com
Routing
SPRING Working GroupSRv6, Network Programming, Inter-LayerThis document defines a new SRv6 function which can be used for SRv6
based inter-layer network programming. It is a variant of the SRv6 End.X
behavior which is called "End.XU". Instead of pointing to an interface
with layer-3 adjacency, the End.XU behavior points to an underlay
interface which connects to a remote layer-3 node via underlying paths
or connections that may be invisible in the L3 topology.In many network scenarios, operator owns a multi-layered network. In
layer-3, the technology has converged to IP, while there can be
different technologies in the layer-2 and layer-1. In such networks, the
cross-layer planning and optimization is considered more efficient than
independent planning and operation of the layer-3 and the underlying
networks in terms of resource utilization and SLA assurance, but are
also considered more complicated. Thus a mechanism for flexible
inter-layer network integration is desired.Segment Routing over IPv6 (SRv6) enables a
network operator or an application to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet
header. Currently SRv6 does not consider about the network layers under
the IP layer. However, with the capability of SRv6 network programming,
it is possible to achieve seamless integration between IP (layer-3) and
the underlying (layer-2 and layer-1) networks.Following the SRv6 network programming concept, a new SRv6 behavior
is defined for sending packet through an underlay interface, which
connects to underlay links or connections between two layer-3 nodes. The
underlay link or connection may be realized using either a Metro
Transport Network (MTN) path, an
ODUk or a DWDM connection. Such a SRv6 behavior can be considered as a
variant of the SRv6 END.X behavior as defined in . The End.XU behavior points to an underlay interface
which connects to a remote layer-3 node via an underlying path or
connection. Different from an L3 adjacency, the underlay path or
connection can be unidirectional and does not require bidirectional
check. Thus the underlay path or connection is invisible in the L3
topology and will not be used for layer-3 route computation (e.g. SPF).
However, this may be the expected behavior when the underlay paths or
connections are provisioned for carrying specific types of services. The
SRv6 End.XU SIDs can be used together with other types of SRv6 SIDs to
build SRv6 SID lists for inter-layer network programming.This document first describes the typical use cases of SRv6
inter-layer network programming, then new SRv6 End.XU behavior for
inter-layer network programming is defined. The application of SRv6
End.XU in typical scenarios is also illustrated with examples.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.In many network scenarios, the underlay of the IP network is an
optical network. The IP network and optical network are usually
managed separately, the optical network works as an underlay which is
invisible to the IP network. In some cases, the optical path resource
and the IP path resource may not be one-to-one mapping, the redundant
optical paths may not be fully used by the IP layer. In some other
cases, there may be optical paths between non-adjacent IP nodes thus
they are not visible in the L3 topology, and thus they can not be used
for carrying traffic based on layer-3 routing.The architecture of Metro Transport Network (MTN) is defined in
. In an MTN based network, network nodes
can support two forwarding modes: per-hop IP packet forwarding and the
MTN Path (MTNP) layer cross-connect. An MTN path is a multi-hop
transport path which may be established between any two nodes in the
MTN network, and the intermediate nodes of the MTN path will forward
the traffic solely based on the pre-established MTN cross-connect
without IP layer lookup. Thus an MTN path is an underlay connection
between two remote MTN nodes. Although in some cases it is possible to
set up a layer-3 adjacency between the two endpoints of the MTN path,
it will make the provisioning of MTN path complicated. Moreover, in
some cases the two endpoints may reside in different IGP areas or
ASes, which makes a layer-3 adjacency between them more challenging.
Since the MTN paths are not visible in the L3 topology, it is
difficult to compute and establish an inter-layer path which consists
of both the layer-3 network segments and the MTN paths.This section defines a new SRv6 behavior for the underlay
cross-connect.The "Endpoint with Underlay cross-connect" behavior ("End.XU" for
short) is a variant of the End.X behavior defined in . Its main use is for inter-layer network programming
and traffic engineering.Any SID instance of this behavior is associated with an underlay
interface, which connects to one or more underlay links or
connections.When N receives a packet destined to S and S is a local End.XU SID, N
does the following:Note that the underlay interface and the associated connection in
step 15 SHOULD be established before the associated End.XU SID is
announced into the network.End.XU SIDs MAY be announced using IGP or BGP-LS in a similar way to
the announcement of the End.X SIDs, while they need to be distinguished
from the End.X SID by both the network nodes and the network controller.
The detailed protocol extension will be described in a separate
document. Then the network controller or a headend node could use the
End.XU SIDs together with other types of SRv6 SIDs to build SID lists
for inter-layer network paths.Assuming that an operator owns both the IP and optical network, and
the operator needs to deploy E2E service across IP and optical
network, with traditional approaches the planning and service
provisioning would be complex and time consuming due of the manual
synergy needed between the operator's IP team and optical team. With
the introduction of SRv6 and the End.XU behavior, one simplified
approach for IP and optical integration is to build a SID list that
integrates the path in both the IP layer and the optical layer.As the optical layer is not packet based, source routing mechanism
can not be directly used in the optical network. However, the
abstracted optical paths (e.g., with ODUk or DWDM) could be exposed to
the control system of the IP network using the SRv6 End.XU SIDs, and
some of the attributes of the optical paths may also be provided.
Based on this information, IP-optical inter-layer paths can be
programmed to meet some specific service requirements, such as low
latency.In Figure 1, P1 to P8 are IP nodes, and O1 to O6 are optical nodes.
Assume the operator needs to deploy a low latency path between P7 and
P8. With normal segment routing, an IP layer path with the segment
list {P7, P1, P2, P3, P8} can be used. But if an optical path from O1
to O3 exists, and the End.XU SID defined in this document is used to
announce this optical path as an underlay connection with specific
attributes into the IP network, the headend node or the controller in
IP layer can program an inter-layer path along {P7, P1, End.XU (O1,
O2, O3), P3, P8} which may provide lower latency.The optical path between O1 and O3 may be created in advance or as
a result of the request from the IP layer. The creation should be done
by the optical network controller (not shown in the Figure). The
details of the process are out of scope of this document, and may
refer to .There is also another case of IP and Optical integration. Assume
there are two optical paths between P1 and P2. One is {P1, O1, O2, P2}
, and the other is {P1, O1, O4, O5, O2, P2}. Two separate End.XU SIDs
are allocated for these two underlay connections separately. One is
End.XU P1::C2 for the underlay path {P1, O1, O2, P2}, and the other is
End.XU P1::C45 for the path {P1, O1, O4, O5, O2, P2}. The headend P7
or the IP network controller will be informed about these two SRv6
End.XU SIDs and the associated path attributes, so that the headend or
the controller can program different end-to-end inter-layer paths
using SID lists with different End.XU SIDs for services with different
SLA requirements.Assuming that an operator owns both an MTN network domain and an IP
network domain. In the MTN network, each MTN node has both the layer-3
functionality and the MTN Path layer functionality. In layer-3, all
the MTN nodes are in a layer-3 network topology, which connects to the
IP network domain. In the MTN Path Layer, a set of MTN paths are
provisioned between the selected pairs of MTN nodes. In the MTN
network, different types of services may be carried using either a
layer-3 path, or an MTN path, or an inter-layer path comprising of
both the layer-3 links and the MTN path as different segments. In
addition, For some type of services, end-to-end paths across the IP
domain and the MTN domain are needed, which is comprised of both the
layer-3 paths and the MTN path as different segments.Figure 2 gives an example of a network with a MTN domain and an IP
domain. M1 to M7 are MTN nodes, and P1 to P4 are IP nodes. The same
set of MTN nodes builds two separate network layers. The topology in
the IP layer shows the layer-3 connectivity between the MTN nodes and
the connectivity with the IP network domain, while the topology in the
MTN Path layer shows the MTN paths between the selected pair of MTN
nodes. An end-to-end path from M7 to P5 can be established in layer-3
using a SID list representing the layer-3 path {M7, M1, M2, M3, P1,
P2, P5}. While for services which require low latency, an end-to-end
path consisting of both the layer-3 segments and MTN paths could be
established using an SRv6 SID list representing the path {M7, M1::C3,
P1, P2, P5}, where the End.XU SID M1::C3 represents the MTN path
M1'-M3'.This shows that it is convenient to use an integrated SID list to
program an inter-layer path both within the MTN domain, and across the
IP and MTN domain using the combination of L3 SRv6 SIDs and the End.XU
SIDs.TBDThis document defines a new SRv6 Endpoint behavior called END.XU.IANA has allocated the following code points for different flavors of
End.XU from the "SRv6 Endpoint Behaviors" sub-registry in the
"Segment-routing with IPv6 data plane (SRv6) Parameters" registry:The authors would like to thank Xiaodong Chang, Yongjian Hu, Ketan
Talaulikar and Zhibo Hu for their review and comments.ITU-T G.8310: Architecture of the metro transport
networkITU-T