The Per-Path Service
Instruction (PPSI) Option
Juniper Networks
2251 Corporate Park Drive
Herndon
20171
Virginia
USA
rbonica@juniper.net
NTT Communications Corporation
3-4-1 Shibaura, Minato-ku
Tokyo
108-8118
Japan
: y.kamite@ntt.com
Verizon
22001 Loudoun County Parkway
Ashburn
Virginia
20147
USA
chris.lenart@verizon.com
Reliance Jio
3010 Gaylord PKWY, Suite 150
Frisco
Texas
75034
USA
Ning.So@ril.com
Reliance Jio
3010 Gaylord PKWY, Suite 150
Frisco
Texas
75034
USA
Fengman.Xu@ril.com
Hughes Network Systems
11717 Exploration Lane
Germantown
Maryland
20876
USA
greg.presbury@hughes.com
Baidu
No.10 Xibeiwang East Road Haidian District
Beijing
100193
P.R. China
phdgang@gmail.com
China Telecom
109 West Zhongshan Ave, Tianhe District
Guangzhou
P.R. China
zhuyq.gd@chinatelecom.cn
China Telecom
109 West Zhongshan Ave, Tianhe District
Guangzhou
P.R. China
yanggm.gd@chinatelecom.cn
ByteDance
Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian
District
Beijing
100000
P.R. China
yifeng.zhou@bytedance.com
INT Area
6man
IPv6
VPN
Destination Option
SRv6+ encodes Per-Path Service Instructions (PPSI) in a new IPv6
option, called the PPSI Option. This document describes the PPSI
Option.
An SRv6+ path
provides unidirectional connectivity from its ingress node to its egress
node. While an SRv6+ path can follow the least cost path from ingress to
egress, it can also follow any other path.
SRv6+ paths are encoded as IPv6 header
chains. When an SRv6+ ingress node receives a packet, it encapsulates
the packet in an IPv6 header chain. It then forwards the encapsulated
packet to the path's egress node. When the egress node receives the
packet, it processes the SRv6+ payload (i.e., the original packet).
SRv6+ paths are programmable. They support several instruction types,
including Per-Path Service Instructions (PPSI). PPSIs determine how path
egress nodes process SRv6+ payloads. In the absence of a PPSI, the
egress node processes SRv6+ payloads as described in .
The following are examples of PPSIs:
Remove any SRv6+ encapsulation and forward the SRv6+ payload
through a specified interface.
Remove any SRv6+ encapsulation and forward the SRv6+ payload
using a specified routing table.
SRv6+ encodes PPSIs in a new IPv6 option, called the PPSI Option.
This document describes the PPSI Option.
PPSIs can be used to support Virtual Private Networks (VPN).
Therefore, of this document describes VPN
technology and how PPSIs can be used to support a VPN.
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.
PPSI Identifiers identify PPSIs. When a path egress node instantiates
a PPSI, it also allocates a PPSI Identifier and associates the PPSI with
the identifier.
PPSI Identifiers have node-local significance. This means that a path
egress node must assign a unique PPSI Identifier to each PPSI that it
instantiates. However, one path egress node can assign a PPSI Identifier
to an instruction that it instantiates, while another path egress node
can assign the same PPSI Identifier to a different PPSI that it
instantiates.
The PPSI Option contains the following fields:
Option Type: 8-bit selector. PPSI option. Value TBD by IANA.
(Suggested value: 144). See Note below.
Opt Data Len - 8-bit unsigned integer. Length of the option, in
octets, excluding the Option Type and Option Length fields. This
field MUST be set to 4.
PPSI identifier - (32-bit selector). Identifies a PPSI.
The SRv6+ PPSI option MAY appear in a Destination Options header that
precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop
Options header or in a Destination Options header that precedes a
Routing header.
When the SRv6+ PPSI option appears in a Destination Options header,
it MUST be the only option listed in the header. This is because the
PPSI defines all path egress node behaviors.
NOTE : The highest-order two bits of the Option Type (i.e., the "act"
bits) are 10. These bits specify the action taken by a destination node
that does not recognize the option. The required action is to discard
the packet and, regardless of whether or not the packet's Destination
Address was a multicast address, send an ICMPv6 Parameter Problem, Code 2, message to the
packet's Source Address, pointing to the unrecognized Option Type.
The third highest-order bit of the Option Type (i.e., the "chg" bit)
is 0. This indicates that Option Data cannot be modified along the path
between the packet's source and its destination.
As per , the Destination Options header
includes a Next Header field. The Next Header field identifies the
header following the Destination Options header.
SRv6+ can carry Ethernet payload after a Destination option header.
Therefore, this document requests IANA to assign a protocol number for
Ethernet. (The suggested value is 143.)
SRv6+ domains MUST NOT span security domains. In order to enforce
this requirement, security domain edge routers MUST do one of the
following:
Discard all inbound SRv6+ packets
Authenticate all inbound SRv6+ packets
IANA is requested to allocate a code point from the Destination
Options and Hop-by-hop Options registry
(https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2).
This option is called "Per-Path Service Instruction Option". The "act"
bits are 10 and the "chg" bit is 0. The suggested value is 144.
IANA is also requested to allocate a code point for Ethernet from the
Assigned Internet Protocol Numbers registry
(https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
The suggested value is 143.
Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert, John Leddy and
Tony Li for their comments.
Virtual Private Network (VPN) technologies allow network providers to
emulate private networks with shared infrastructure. For example, assume
that red sites and blue sites connect to a provider network. The
provider network facilitates communication among red sites and
facilitates communication among blue sites. However, it prevents
communication between red sites and blue sites.
The IETF has standardized many VPN technologies, including:
Layer 2 VPN (L2VPN).
Layer 3 VPN (L3VPN) .
Virtual Private LAN Service (VPLS)
.
Ethernet VPN (EVPN) .
Pseudowires .
The above-mentioned technologies include the following
components:
Customer Edge (CE) devices.
Provider Edge (PE) devices.
Routing Instances.
Service Instructions.
Service Instruction Identifiers.
Transport tunnels.
CE devices participate in closed communities called VPNs. CEs that
participate in one VPN can communicate with one another but cannot
communicate with CEs that participate in another VPN.
CE devices connect to provider networks through PE devices. Each PE
maintains one Routing Instance for each VPN that it supports. A Routing
Instance is a VPN specific Forwarding Information Base (FIB). In EVPN,
Routing Instances are called Ethernet Virtual Instances (EVI).
Assume that one CE sends a packet through a provider network to
another CE. The packet enters the provider network through an ingress PE
and leaves the provider network through an egress PE. The packet may
traverse one or more intermediate nodes on route from PE to PE.
When the ingress PE receives the packet, it:
Identifies the Routing Instance that supports the originating
CE's VPN.
Searches that Routing Instance for the packet's destination.
If the search fails, the ingress PE discards the packet. If the
search succeeds, it yields the following:
A Service Instruction Identifier.
The egress PE's IP address.
The ingress PE prepends the Service Instruction Identifier and
a transport header to the packet, in that order. It then forwards the
packet through a transport tunnel to the egress PE.
The egress PE removes the transport header, if it has not already
been removed by an upstream device. It then examines and removes the
Service Instruction Identifier. Finally, it executes a service
instruction that is associated with the Service Instruction Identifier.
The service instruction causes the egress PE to forward the packet to
its destination (i.e., a directly connected CE).
In the above-mentioned VPN technologies, the ingress PE encodes
Service Instruction Identifiers in Multiprotocol
Label Switching (MPLS) labels. Depending upon the transport
tunnel type, the transport header can be:
A MPLS label or label stack.
An IPv4 header.
An IPv6 header.
A Generic Routing Encapsulation (GRE)
header encapsulated in IPv4 or IPv6.
Some PE devices cannot process MPLS headers. While these devices have
several alternatives to MPLS-based transport tunnels, they require an
alternative to MPLS-based encoding of Service Instruction Identifiers.
The PPSI Option can be used to encode Service Instruction Identifiers .
It is applicable when VPN payload is transported over IPv6.