SRv6 for Inter-Layer Network Programming

2.1. IP and Optical Inter-layer Path 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 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 Path 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.1. SRv6 END.XU Behavior

The "Endpoint with Underlay cross-connect" behavior ("End.XU" for short) is a variant of the SRv6 End.X behavior as defined in [RFC8986]. Its main use is for SRv6 based inter-layer path programming and traffic engineering. Instead of pointing to an interface with layer-3 adjacency, the End.XU behavior points to an underlay interface, which connects to a remote network node via underlying links or connections that may be invisible in the L3 network topology. Thus the End.XU behavior can be used to steer packets through an underlay link or connection to a remote node.¶

Unlike an L3 link, an underlying link or connection does not require bi-directional check thus can be unidirectional. Thus the underlay links or connections are invisible in the L3 topology and can not be used in IP distributed route computation (e.g. SPF). However, this is just the expected behavior in some inter-layer programming scenarios, 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], 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 path programming.¶

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:¶

   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 is out of the scope of this document, and will be described in a separate document. With the collected information of End.XU SIDs, the network controller or headend nodes could use End.XU SIDs together with other types of SRv6 SIDs to build SRv6 SID lists for inter-layer TE path programming.¶

3.2. SRv6 END.BXC Behavior

The "Endpoint Bound to an underlay Channel" behavior ("End.BXC" for short) is a variant of the SRv6 End behavior. It is an SRv6 instantiation of a Binding SID. Any SID instance of this behavior is associated with an underlay tunnel (e.g.L1 channel) X. Typical types of the L1 channel include MTN, and OTN.¶

This End.BXC SID can support the Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors defined in [RFC8986] either individually or in combinations. The SRH processing of the End.BXC behavior with PSP, USP, and USD is the same as [RFC8986]¶

When N receives a packet destined to S and S is a local End.BXC SID, the line S15 from the End processing defined in [RFC8986] is replaced by the following:¶

S15  Forward the packet to the new destination via underlay tunnel X.

Another option is an SRv6 End.BXC behavior may require additional information for its processing. This information may be encoded in the ARG part of the SID as defined in [RFC8986].For example, the high bit part of ARG may be used to encode Channel Type, and the low bit part of ARG may be used to encapsulate Channel ID. The Channel is uniquely identified by channel type and channel ID. With this option, N gets the channel type and channel ID directly from the ARG, and then find the corresponding underlying channel. Using this option, the number of SID forwarding entries can be reduced.¶

The End.BXC SIDs can be allocated either by a centralized network controller or by the network nodes, and the END.BXC SIDs MAY be announced via Netconf/YANG, BGP, and PCEP in a similar way to the announcement of the Binding SIDs. However, the association between the underlying connections and the BXC SID needs to be announced. The detailed protocol extensions are out of the scope of this document and will be described in a separate document.¶

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.¶

 .......................................... ...........................
 .                                        . .                         .
 .          +----+     +----+     +----+  . . +----+     +----+       .
 .          | 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

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, with SRv6 inter-layer programming, 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 SRv6 SID M1::C3 represents the underlay 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 SRv6 L3 SIDs and the SRv6 inter-layer SID.¶

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>.

[RFC8754]

Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[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-12, 5 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-poi-applicability-12>.

[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.