SPRING Working Group Y. Liu
Internet Draft China Mobile
Intended status: Standards Track C. Lin
Expires: January 11, 2023 H. Li
New H3C Technologies
L. Gong
China Mobile
July 10, 2022
Network Resource Partition Identifier (NRP-ID) in SRv6 segment
draft-liu-spring-nrp-id-in-srv6-segment-00
Abstract
This document proposes a method to carry the Network Resource
Partition Identifier (NRP-ID) with the packet in the SRv6 segment.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 11 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expire January, 2023 [Page 1]
Internet-Draft NRP-ID In SRv6 segment July 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
1.1. Requirements Language.....................................3
2. Encoding NRP-ID in SRv6 segment................................3
3. Deployment consideration of NRP-ID In segment..................4
4. NRP-ID position information advertisement......................5
4.1. Static configuration mode.................................5
4.2. Dynamic advertising mode..................................6
5. Behavior of headend............................................6
6. Behavior of endpoint...........................................7
7. Behavior of transit node.......................................8
8. Example........................................................9
9. IANA Considerations...........................................10
10. Security Considerations......................................10
11. References...................................................11
11.1. Normative References....................................11
Authors' Addresses...............................................12
1. Introduction
Network slicing provides the ability to partition a physical network
into multiple isolated logical networks of varying sizes,
structures, and functions so that each slice can be dedicated to
specific services or customers. [I-D.ietf-teas-ietf-network-slices]
defines the term "IETF Network Slice" and establishes the general
principles of network slicing in the IETF context. [I-D.cheng-teas-
network-slice-usecase] describes several use cases of IETF Network
Slice. [I-D.ietf-teas-ns-ip-mpls] proposes a solution to realize
network slicing in IP/MPLS networks. Network nodes need to identify
a packet belonging to a network slice before it can apply the proper
forwarding treatment, so a slice ID must be carried in each packet.
Packets belong to a network slice need to be forwarded using the
specific network resources. [I-D.draft-ietf-teas-ietf-network-
Liu, et al. Expires January, 2023 [Page 2]
Internet-Draft NRP-ID In SRv6 segment July 2022
slices] defines the network resource mapped to the network slice as
NRP, that is, the Network Resource Partition, and defines the NRP-ID
to identify the NRP used in the forwarding process.
In a network that provides slicing services, the NRP-ID can be
carried in the packet. In the process of packet forwarding, the
routers on the forwarding path can extract NRP-ID from the packet,
determine the NRP to which the packet belongs, and then forward the
packet using the resources associated with the NRP.
Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Per-path states of Intermediate nodes are eliminated
thanks to source routing. The headend node steers a flow into an SR
Policy. The packets steered into an SR Policy carry an ordered list
of segments associated with that SR Policy.
When SRv6 network provides network slicing service, it is also
necessary to consider how to carry NRP-ID with packet. This document
proposes a method to carry the NRP-ID in the SRv6 network. By
setting the NRP-ID in the SRv6 segment, the SRv6 endpoint or transit
node can be aware the NRP to which the packet belongs and carry out
relevant forwarding processing.
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. Encoding NRP-ID in SRv6 segment
The structure of SRv6 segment is defined in RFC[8986]. An SRv6
segment consists of three parts, LOC:FUNCT:ARG.
+------------------------------------------------------------------+
| Locator | Function | Argument |
+------------------------------------------------------------------+
<--------- LOC ---------><- FUNCT -><----------- ARG-------------->
Figure 1: structure of segment
After the packet enters the SRv6 domain, the ingress node (headend)
adds SRv6 Encapsulation to packet. In SRv6 TE (traffic engineer)
mode, the headend node encapsulates an IPv6 header and an SRH header
at the same time. A group of SRv6 segments is encapsulated in the
Liu, et al. Expires January, 2023 [Page 3]
Internet-Draft NRP-ID In SRv6 segment July 2022
SRH header to indicate the forwarding path. NRP-ID can be carried in
segment to identify the NRP to which the packet belongs.
This document proposes to use the ARG part of the segment to carry
the NRP-ID.
+------------------------------------------------------------------+
| Locator | Function | NRP-ID |
+------------------------------------------------------------------+
<--------- LOC ---------><- FUNCT -><----------- ARG-------------->
Figure 2: Encoding NRP-ID in segment
3. Deployment consideration of NRP-ID In segment
In the SRv6 TE mode, multiple segments are encoded in the SRH. The
last segment in the SRH is usually the service or End SID of the
tailend node and does not need to carry the NRP-ID.
Other segments in SRH are usually End or End.X segments, which are
used to guide intermediate endpoint nodes to forward packets. These
segments do not need argument and can carry NRP-ID.
Different segments can carry the same or different NRP-ID, which is
arranged by the controller or operator by CLI according to the
actual requirement.
Segment[0]:
+------------------------------------------------------------------+
| Locator5 | Function | Argument |
+------------------------------------------------------------------+
Segment[1]
+------------------------------------------------------------------+
| Locator4 | Function | NRP-ID2 |
+------------------------------------------------------------------+
Segment[2]
+------------------------------------------------------------------+
| Locator3 | Function | NRP-ID2 |
+------------------------------------------------------------------+
Segment[3]
+------------------------------------------------------------------+
| Locator2 | Function | NRP-ID1 |
+------------------------------------------------------------------+
Segment[4]
+------------------------------------------------------------------+
| Locator1 | Function | NRP-ID1 |
+------------------------------------------------------------------+
Figure 3: Encoding NRP-ID in segment list
Liu, et al. Expires January, 2023 [Page 4]
Internet-Draft NRP-ID In SRv6 segment July 2022
4. NRP-ID position information advertisement
If the network slicing service needs to be supported, when creating
a locator, the SRv6 node needs to determine the encoding position of
NRP-ID in the segment according to its own role.
The locator and encoding positions of NRP-ID need to be advertised
to the controller and other network nodes. With this information,
the controller arranges the SRv6 policy, and other network nodes
need to extract the NRP-ID from address during forwarding.
4.1. Static configuration mode
In the static configuration mode, configure the locator encoding
information on the controller and network nodes respectively. For
the convenience of description, the locator carrying NRP-ID is named
slice prefix in this document.
All nodes that support network slicing need to be configured,
including SRv6 nodes and IPv6 only nodes.
The aggregation attribute of locator can be used. The following
figure is an example. The P nodes only provide End/End.x type
segments, and the positions used to encode NRP-ID are usually the
same. Therefore, common prefix can be configured to indicate the
position of NRP-ID.
If the encoding position of a P node is different from that of most
nodes, the slice prefix corresponding to the locator of the P node
can be configured separately to specify its encoding position.
These slice prefixes will create a local slice prefix table (LSPT)
on the forwarding plane. When forwarding packets, the network node
uses the destination address to lookup the LSPT according to the
longest matching principle, and then extracts the NRP-ID from the
destination address according to the information of the hit table
entry.
Referring to the topology and locators of each node in the Figure 4,
the following slice prefix can be configured.
The encoding positions of P1 and P4 nodes are the same, and a slice
prefix corresponding to common prefix can be configured to identify
the coding position as the low 16 bits. The encoding position of P3
is 96bit to 112bit of segment, so a slice prefix corresponding to
its locator is configured separately to explain its coding position
Liu, et al. Expires January, 2023 [Page 5]
Internet-Draft NRP-ID In SRv6 segment July 2022
Slice-Prefix1: 2001:1:1::/64 (common prefix)
NRP-ID Position: [112..127]
Slice-Prefix2: 2001:1:1:0:130::/80 (locator for P3)
NRP-ID Position: [96..112] in segment
IPv6-only
+-----+ +----+ +----+ +----+ +----+ +-----+
--+ PE1 +---+ P1 +---+ P2 +---+ P3 +---+ P4 +---+ PE2 +---
+-----+ +----+ +----+ +----+ +----+ +-----+
SRv6-node SRv6-node SRv6-node
common Prefix: 2001:1:1::/64
locator
P1: 2001:1:1:0:110::/80 for End/End.x
P3: 2001:1:1:0:130::/80 for End/End.x
P4: 2001:1:1:0:140::/80 for End/End.x
Figure 4: example topology for slice prefixes
4.2. Dynamic advertising mode
To simplify the configuration, slice prefix can be advertised to
network nodes in the domain through IGP and to controllers through
BGP-LS. This reduces the configuration of controllers and SRv6
nodes.
However, nodes that only support IPv6 need to be configured as
described in the previous section.
Relevant protocol extensions will be provided in subsequent
versions.
5. Behavior of headend
If the network slice function is enabled, the SRv6 headend node
determines the network slice to which the customer traffic belongs
according to the relevant policies.
The headend node steers the customer traffic to the SRv6 policy and
encapsulates the IPv6 header and SRH header for the customer
traffic. The headend node encapsulates the segment list of the SRv6
policy in the SRH header.
Liu, et al. Expires January, 2023 [Page 6]
Internet-Draft NRP-ID In SRv6 segment July 2022
At the same time, set NRP-ID into segment. These NRP-IDs can be the
same or different values according to actual requirement.
Generally, the nodes along the route of the message use the same
NRP-ID to identify the NRP associated with the network slice.
Therefore, when the headend node encapsulates the segment list in
the SRH, it writes the same NRP-ID into segments except the last
segment.
In some special cases, such as cross domain scenarios, different
NRP-IDs may be used on the forwarding path. In this case, the
controller may need to write the NRP-ID into each segment of the
segment list in advance, and then issue the SRv6 policy to the
headend node. The headend node only needs to use SRv6 policy to
encapsulate customer traffic.
+-----------------------------------------------------------+
| IPv6 Header |
. Source IP Address = IPv6 Address of Ingress .
. Destination IP Address = SegmentList[SL] .
. Next-Header = SRH (43) .
. .
+-----------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment0> .
. <Segment1|NRP-ID1> .
. <Segment2 NRP-ID2> .
. <SegmentN|NRP-IDN> .
. .
+-----------------------------------------------------------+
| Payload |
. .
+-----------------------------------------------------------+
Figure 5: Format of SRv6 TE with slice ID
6. Behavior of endpoint
When a SRv6 node receives a packet, the destination address of the
packet is the segment instantiated locally by the SRv6 node. At this
time, the SRv6 node processes the packet as endpoint node. The
endpoint node extracts the NRP-ID from the segment and forwards the
packet with the NRP identified by the NRP-ID.
When N receives a packet whose IPv6 DA is S and S is a local End
SID, the pseudo code processed is modified as follows based on
RFC[8986]:
Liu, et al. Expires January, 2023 [Page 7]
Internet-Draft NRP-ID In SRv6 segment July 2022
S01 - S11.
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
Insert Extract NRP-ID from destination address.
Modify:
S15. Uses the NRP-ID to select a NRP and apply NRP policies to
forward packet
S16. }
When N receives a packet whose IPv6 DA is S and S is a local End.X
SID, the pseudo code processed is modified as follows based on
RFC[8986]:
S01 - S11.
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
Insert Extract NRP-ID from destination address.
S14. Update IPv6 DA with Segment List[Segments Left]
Modify:
S15. Submit the packet to the IPv6 module for transmission
to the new destination via a member of J with using the
resource of NRP
S16. }
7. Behavior of transit node
For the transit node, the destination address of the packet is not a
local segment, and only IPv6 forwarding is performed for the packet.
The transit node may be a node that supports SRv6 or a node that
only supports IPv6.
When processing SRv6 packets, the transit node can use the
destination address to lookup the local slice prefix table according
to the longest matching principle. If a prefix is hit, the NRP-ID
could be extracted according to the configuration information.
Therefore, the processing pseudo code can be modified as follows:
Liu, et al. Expires January, 2023 [Page 8]
Internet-Draft NRP-ID In SRv6 segment July 2022
S1. If ((Slice forwarding is enabled) && (Destination address hits
network slice prefix)) {
S2 Extracts NRP-ID from destination address by using the
position information of hit prefix
S2. Uses the NRP-ID to apply NRP policies to forward packet
S3. }
S4. Else {
S5. Forwards the packet without applying any NRP policies
S6. }
8. Example
As shown in the following figure, the IP backbone network deploys
the network slicing service. The network operator has created two
NRPs, NRP1 and NRP2. NRP1 guarantees 100Mbps bandwidth and NRP2
guarantees 200m bandwidth. Set the IDs NRP-ID1 and NRP-ID2 for the
two NRPs respectively.
The IP backbone network provides customers with two network slices.
Network slice1 is mapped to NRP1 and network slice2 is mapped to
NRP2. SRv6 is used to carry traffic and network slicing services.
Along with the forwarding path <PE1-P1-P2-PE2>, dedicated queues
with guaranteed bandwidth for NRP1 and NRP2 are configured at
corresponding interfaces of each router. Taking the interface P1-P2
of router P1 as an example, Queue 1 is configured with NRP-ID1 and
guaranteed bandwidth of 100Mbps, and Queue 2 is configured with NRP-
ID2 and 200Mbps. When P1 transmits a packet through interface P1-P2,
the NRP-ID carried in the destination address is checked.
If NRP-ID1 is encapsulated in the destination address, P1 uses queue
1 to transmit the packet. If NRP-ID2 is encapsulated in the
destination address, P1 uses queue 2 to transmit the packet.
Liu, et al. Expires January, 2023 [Page 9]
Internet-Draft NRP-ID In SRv6 segment July 2022
.................................
: IP Backbone :
CPE PE1 P1 P2 PE2 ......
|----| |---| NRP1|---| NRP1|---| NRP1|---| : DC :
| o---|o-o|-----|o-o|-----|o-o|-----|o-o|--o :
| o---|o-o|-----|o-o|-----|o-o|-----|o-o|--o :
|----| |---| NRP2|---| NRP2|---| NRP2|---| :....:
: :
:...............................:
+-------------+ +-------------+
|DA= | |DA= |
|P1.End|NRP-ID| |P2.VPNSID |
+-------------+ +-------------+
|SRH | |SRH |
|PE2.VPNSID | |PE2.VPNSID |
|P3.End|NRP-ID| |P3.End|NRP-ID|
|P1.End|NRP-ID| |P1.End|NRP-ID|
+-------+ <-> +-------------+<...>+-------------+ <-> +-------+
|Payload| | Payload | | Payload | |Payload|
+-------+ +-------------+ +-------------+ +-------+
|----| Interface: P1-P2
| | ----------------------------------
| | >>>>>>Queue 1: NRP-ID1, 100Mbps>>>>>>
| P1 | >>>>>>Queue 2: NRP-ID2, 200Mbps>>>>>>
| | >>>>>> ... >>>>>>
| | ----------------------------------
|----|
Figure 6: example topology
9. IANA Considerations
This document has no IANA actions.
10. Security Considerations
The security requirements and mechanisms described in [RFC8402] and
[RFC8754] also apply to this document.
This document does not introduce any new security consideration.
Liu, et al. Expires January, 2023 [Page 10]
Internet-Draft NRP-ID In SRv6 segment July 2022
11. References
11.1. Normative References
[I-D.cheng-teas-network-slice-usecase] Cheng, W., Jiang, W., Chen,
R., Gong, L., and S. Peng, "IETF Network Slice use cases",
draft-cheng-teas-network-slice-usecase-01 (expired),
August 2021.
[I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J.,
Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
Tantsura, "Framework for IETF Network Slices", draft-ietf-
teas-ietf-network-slices-12 (work in progress), June 2022.
[I-D.ietf-teas-ns-ip-mpls] Saad, T., Beeram, Dong, J., Wen, B.,
Ceccarelli, D., Halpern, J., Peng, S., Chen, R., Liu, X.,
Contreras, L. M., Rokui, R., and L. Jalil, "Realizing
Network Slices in IP/MPLSNetworks", Work in Progress,
Internet-Draft, draft-ietf-teas-ns-ip-mpls-00, June 2022,
<https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-
mpls-00.txt>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg,
L.,Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,July
2018, <https://www.rfc-editor.org/info/rfc8402>.
[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
0.17487/RFC8986, February 2021, <https://www.rfc-
editor.org/info/rfc8986>.
Liu, et al. Expires January, 2023 [Page 11]
Internet-Draft NRP-ID In SRv6 segment July 2022
Authors' Addresses
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Hao Li
New H3C Technologies
China
Email: lihao@h3c.com
Liyan Gong
China Mobile
China
Email: gongliyan@chinamobile.com
Liu, et al. Expires January, 2023 [Page 12]