Internet DRAFT - draft-dong-spring-srv6-inter-layer-programming
draft-dong-spring-srv6-inter-layer-programming
SPRING Working Group L. Han
Internet-Draft China Mobile
Intended status: Standards Track J. Dong
Expires: 2 September 2024 Huawei Technologies
Z. Du
M. Wang
China Mobile
1 March 2024
SRv6 for Inter-Layer Network Programming
draft-dong-spring-srv6-inter-layer-programming-07
Abstract
The Segment Routing over IPv6 (SRv6) Network Programming framework
enables a network operator or an application to specify a packet
processing program by encoding a sequence of instructions in the IPv6
packet header.
Following the SRv6 Network Programming concept, this document defines
an SRv6 based mechanism for inter-layer network programming, which
can help to integrate the packet network layer with its underlying
layers efficiently. A new SRv6 behavior called End.XU is introduced,
which is a variant of the SRv6 End.X behavior. 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 links or connections that are invisible in the L3 network
topology. The applicability of the End.XU behavior in typical inter-
layer network programming scenarios is also illustrated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 September 2024.
Han, et al. Expires 2 September 2024 [Page 1]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use Cases of SRv6 Inter-Layer Programming . . . . . . . . . . 3
2.1. IP and Optical Inter-layer Programming . . . . . . . . . 3
2.2. IP and MTN Inter-layer Programming . . . . . . . . . . . 4
3. SRv6 END.XU Behavior . . . . . . . . . . . . . . . . . . . . 4
4. Application of SRv6 End.XU . . . . . . . . . . . . . . . . . 6
4.1. IP and Optical Integration . . . . . . . . . . . . . . . 6
4.2. IP and MTN Integration . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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 layer-2 and below. 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 it is also considered more complicated. Thus a
mechanism for flexible and efficient inter-layer network integration
is desired.
Segment Routing over IPv6 (SRv6) [RFC8986] 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
Han, et al. Expires 2 September 2024 [Page 2]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
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 below) networks.
Following the SRv6 network programming concept, a new SRv6 behavior
called End.XU is defined for sending packets through an underlay
interface, which connects to a remote layer-3 node via underlying
links or connections. The SRv6 End.XU behavior can be considered as
a variant of the SRv6 END.X behavior as defined in [RFC8986]. Unlike
an L3 adjacency, the underlying links or connections can be
unidirectional and does not require bidirectional check. Thus the
underlay links or connections are invisible in the L3 topology and
will not be used for IP distributed route computation (e.g. SPF).
However, this may just be the expected behavior in inter-layer
programming where the underlay links or connections are provisioned
for traffic engineering for specific types of services. Such
underlying links or connections may be realized using either Metro
Transport Network (MTN) paths [ITU-T_G.8310], or ODUk or DWDM
connections. 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 inter-layer
network programming, then a new SRv6 End.XU behavior for inter-layer
network programming is introduced. The applicability of SRv6 End.XU
behavior in typical inter-layer network programming scenarios is also
illustrated.
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use Cases of SRv6 Inter-Layer Programming
2.1. IP and Optical Inter-layer Programming
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
normally invisible to the IP network. In some cases, the optical
path resources and the IP path resources may not be one-to-one
mapping, which makes the redundant optical paths not fully used by
the IP layer. In some other cases, there may be optical paths
Han, et al. Expires 2 September 2024 [Page 3]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
between non-adjacent IP nodes thus they are not visible in the L3
topology, thus they can not be used for carrying traffic based on IP
routing. However, such optical paths may be used for inter-layer
traffic engineering.
2.2. IP and MTN Inter-layer Programming
The architecture of Metro Transport Network (MTN) is defined in
[ITU-T_G.8310]. 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 underlay
transport path which may be established between any two nodes in the
MTN network, and the intermediate nodes on the MTN path will forward
the traffic based on the pre-established MTN cross-connect without IP
table lookup. Thus an MTN path is considered as 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. Last but not the least, the MTN path may be
provisioned unidirectionally, which cannot pass the bidirectional
connectivity check required for a layer-3 link. Since the MTN paths
are usually not visible in the L3 topology, it is difficult to
compute and establish an end-to-end inter-layer path which consists
of both the layer-3 network segments and the MTN paths.
3. SRv6 END.XU Behavior
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 [RFC8986]. Its
main use is for SRv6 based 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 node N receives a packet destined to S and S is a local End.XU
SID, N does the following:
Han, et al. Expires 2 September 2024 [Page 4]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Send the packet through one of the underlay links associated
with the underlay interface identified by S.
S16. }
Note that the underlay interface and the associated links in step 15
SHOULD be established before the associated End.XU SID is announced
into the network.
When forwarding packets through the underlay interface towards the
remote endpoint node, the information required for layer-2
encapsulation may be provisioned via mechanisms such as static
Neighbor Discovery (ND) Cache. The details are out of the scope of
this document.
End.XU SIDs MAY be announced using IGP or BGP-LS in a similar way to
the announcement of the End.X SIDs, while the information about the
underlay connections and the associated End.XU SIDs need to be
distinguished from the layer-3 links and the End.X SIDs. The
detailed protocol extensions will be described in a separate
document. With the collected information of End.XU SIDs, the network
controller or headend nodes could use the End.XU SIDs together with
other types of SRv6 SIDs to build SRv6 SID lists for inter-layer TE
paths.
Han, et al. Expires 2 September 2024 [Page 5]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
4. Application of SRv6 End.XU
4.1. IP and Optical Integration
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 SRv6 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
computed and programmed to meet some specific service requirements,
such as low latency.
----- ----- -----
| P1 |--------| P2 |--------| P3 |
----- ----- -----
/ |. |. |. \
----- / | . | . | . \ -----
| P7 | | . | . | . | P8 |
----- \ | . | . | ./ -----
\ | . | . | / .
----- . ----- . ----- .
| P4 |-------| P5 |--------| P6 | .
----- . ----- . ----- .
. . . . . .
. ===== . ===== . =====
. | O1 |----------| O2 |--------| O3 |
. ===== . ===== . =====
. | . | . |
. | . | . |
. | . | . |
. | . | . |
.| .| .|
===== ===== =====
| O4 |----------| O5 |--------| O6 |
===== ===== =====
Figure 1. IP and Optical Layered Network Topology
Han, et al. Expires 2 September 2024 [Page 6]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
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 TE 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 [I-D.ietf-teas-actn-poi-applicability].
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 can be allocated for these two underlay connections
respectively. 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 SRv6 SID lists with
different End.XU SIDs for services with different SLA requirements.
4.2. IP and MTN Integration
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 for
traffic engineering. In the MTN network, different types of services
may be carried using either a layer-3 path, an end-to-end MTN path,
or an inter-layer path comprising of both the layer-3 links and the
MTN paths as 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.
Han, et al. Expires 2 September 2024 [Page 7]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
.......................................... ...........................
. . . .
. +----+ +----+ +----+ . . +----+ +----+ .
. | M1 |-----| M2 |-----| M3 |------| P1 |-----| P2 | .
. +----+ +----+ +----+ . . +----+ +----+ .
. / | | | . . | | \ .
. +----+ / | | | . . | | \+----+.
. | M7 |/ | | | . . | | | P5 |.
. +----+\ | | | . . | | /+----+.
. \ | | | . . | | / .
. \+----+ +----+ +----+ . . +----+ +----+ .
. | M4 |-----| M5 |-----| M6 |------| P3 |-----| P4 | .
. +----+ +----+ +----+ . . +----+ +----+ .
. . . .
. Layer-3 Topology MTN Network . . IP Network .
. . ...........................
----------------------------------------------------------------------
. MTN Path Layer Topology .
. .
. +----+ +----+ +----+ .
. | M1'|################| M3'| .
. +----+ ## +----+ ## +----+ .
. ## ## .
. +----+ ## ## .
. | M7'| ## .
. +----+ ## ## .
. ## ## .
. +----+ ## +----+ ## +----+ .
. | M4'|################| M6'| .
. +----+ +----+ +----+ .
. .
. .
..........................................
.
Figure 2. A network with MTN Domain and IP Domain
Han, et al. Expires 2 September 2024 [Page 8]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
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 an SRv6 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 inter-
layer 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 integrated SRv6 SID lists to
program inter-layer TE paths both within the MTN domain, and across
the IP and MTN domain using the combination of L3 SRv6 SIDs and the
End.XU SIDs.
5. Security Considerations
TBD
6. IANA Considerations
This 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:
+------+--------+------------------------------------------+-----------+
| Value| Hex | Endpoint Behavior | Reference |
+------+--------+------------------------------------------+-----------+
| 150 | 0x0096 | End.XU | [This ID] |
| 151 | 0x0097 | End.XU with PSP | [This ID] |
| 152 | 0x0098 | End.XU with USP | [This ID] |
| 153 | 0x0099 | End.XU with USD | [This ID] |
| 154 | 0x009A | End.XU with PSP, USP & USD | [This ID] |
| 155 | 0x009B | End.XU with REPPLACE-CSID | [This ID] |
| 156 | 0x009C | End.XU with REPPLACE-CSID & PSP | [This ID] |
| 157 | 0x009D | End.XU with REPPLACE-CSID, PSP, USP & USD| [This ID] |
+------+--------+------------------------------------------+-----------+
Han, et al. Expires 2 September 2024 [Page 9]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
7. Acknowledgements
The authors would like to thank Xiaodong Chang, Yongjian Hu,
Alexander Vainshtein, Ketan Talaulikar and Zhibo Hu for their review
and comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
8.2. Informative References
[I-D.ietf-teas-actn-poi-applicability]
Peruzzini, F., Bouquier, J., Busi, I., King, D., and D.
Ceccarelli, "Applicability of Abstraction and Control of
Traffic Engineered Networks (ACTN) to Packet Optical
Integration (POI)", Work in Progress, Internet-Draft,
draft-ietf-teas-actn-poi-applicability-11, 22 February
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-actn-poi-applicability-11>.
[ITU-T_G.8310]
ITU-T, "ITU-T G.8310: Architecture of the metro transport
network", https://www.itu.int/rec/T-REC-
G.8310-202012-I/en, December 2020.
Authors' Addresses
Liuyan Han
China Mobile
No.32 XuanWuMen West Street
Beijing, 100053
China
Han, et al. Expires 2 September 2024 [Page 10]
Internet-Draft SRv6 Inter-Layer Network Programming March 2024
Email: hanliuyan@chinamobile.com
Jie Dong
Huawei Technologies
Huawei Campus, No.156 Beiqing Road
Beijing, 100095
China
Email: jie.dong@huawei.com
Zongpeng Du
China Mobile
No.32 XuanWuMen West Street
Beijing, 100053
China
Email: duzongpeng@foxmail.com
Minxue Wang
China Mobile
No.32 XuanWuMen West Street
Beijing, 100053
China
Email: wangminxue@chinamobile.com
Han, et al. Expires 2 September 2024 [Page 11]
