draft-ietf-spring-sr-service-programming-01.txt   draft-ietf-spring-sr-service-programming-02.txt 
SPRING F. Clad, Ed. SPRING F. Clad, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track X. Xu, Ed. Intended status: Standards Track X. Xu, Ed.
Expires: May 7, 2020 Alibaba Expires: September 10, 2020 Alibaba
C. Filsfils C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
D. Bernier D. Bernier
Bell Canada Bell Canada
C. Li C. Li
Huawei Huawei
B. Decraene B. Decraene
Orange Orange
S. Ma S. Ma
Mellanox Mellanox
C. Yadlapalli C. Yadlapalli
AT&T AT&T
W. Henderickx W. Henderickx
Nokia Nokia
S. Salsano S. Salsano
Universita di Roma "Tor Vergata" Universita di Roma "Tor Vergata"
November 04, 2019 March 09, 2020
Service Programming with Segment Routing Service Programming with Segment Routing
draft-ietf-spring-sr-service-programming-01 draft-ietf-spring-sr-service-programming-02
Abstract Abstract
This document defines data plane functionality required to implement This document defines data plane functionality required to implement
service segments and achieve service programming in SR-enabled MPLS service segments and achieve service programming in SR-enabled MPLS
and IPv6 networks, as described in the Segment Routing architecture. and IPv6 networks, as described in the Segment Routing architecture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Classification and steering . . . . . . . . . . . . . . . . . 4 3. Classification and Steering . . . . . . . . . . . . . . . . . 4
4. Service segments . . . . . . . . . . . . . . . . . . . . . . 5 4. Service Segments . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 5 4.1. SR-Aware Services . . . . . . . . . . . . . . . . . . . . 5
4.2. SR-unaware services . . . . . . . . . . . . . . . . . . . 6 4.2. SR-Unaware Services . . . . . . . . . . . . . . . . . . . 6
5. SR service policies . . . . . . . . . . . . . . . . . . . . . 7 5. SR Service Policies . . . . . . . . . . . . . . . . . . . . . 7
5.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 8 5.1. SR-MPLS Data Plane . . . . . . . . . . . . . . . . . . . 8
5.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 10 5.2. SRv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 10
6. SR proxy behaviors . . . . . . . . . . . . . . . . . . . . . 11 6. SR Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 11
6.1. Static SR proxy . . . . . . . . . . . . . . . . . . . . . 14 6.1. Static SR Proxy . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 16 6.1.1. SR-MPLS Pseudocode . . . . . . . . . . . . . . . . . 16
6.1.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 17 6.1.2. SRv6 Pseudocode . . . . . . . . . . . . . . . . . . . 17
6.2. Dynamic SR proxy . . . . . . . . . . . . . . . . . . . . 19 6.2. Dynamic SR Proxy . . . . . . . . . . . . . . . . . . . . 23
6.2.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 19 6.2.1. SR-MPLS Pseudocode . . . . . . . . . . . . . . . . . 24
6.2.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 20 6.2.2. SRv6 Pseudocode . . . . . . . . . . . . . . . . . . . 24
6.3. Shared memory SR proxy . . . . . . . . . . . . . . . . . 21 6.3. Shared Memory SR Proxy . . . . . . . . . . . . . . . . . 25
6.4. Masquerading SR proxy . . . . . . . . . . . . . . . . . . 21 6.4. Masquerading SR Proxy . . . . . . . . . . . . . . . . . . 25
6.4.1. SRv6 masquerading proxy pseudocode . . . . . . . . . 22 6.4.1. SRv6 Masquerading Proxy Pseudocode . . . . . . . . . 27
6.4.2. Variant 1: Destination NAT . . . . . . . . . . . . . 23 6.4.2. Destination NAT Flavor . . . . . . . . . . . . . . . 28
6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 23 6.4.3. Caching Flavor . . . . . . . . . . . . . . . . . . . 28
7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 23 7.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 29
7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 24 7.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 24 7.2.1. SRH TLV Objects . . . . . . . . . . . . . . . . . . . 30
7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 25 7.2.2. SRH Tag . . . . . . . . . . . . . . . . . . . . . . . 31
8. Implementation status . . . . . . . . . . . . . . . . . . . . 25 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 31
8.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 26 8.1. SR-Aware Services . . . . . . . . . . . . . . . . . . . . 32
8.2. Proxy behaviors . . . . . . . . . . . . . . . . . . . . . 26 8.2. Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 32
9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 27 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 33
10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 27 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Segment Routing (SR) is an architecture based on the source routing Segment Routing (SR) [RFC8402] is an architecture based on the source
paradigm that seeks the right balance between distributed routing paradigm that seeks the right balance between distributed
intelligence and centralized programmability. SR can be used with an intelligence and centralized programmability. SR can be used with an
MPLS or an IPv6 data plane to steer packets through an ordered list MPLS or an IPv6 data plane to steer packets through an ordered list
of instructions, called segments. These segments may encode simple of instructions, called segments. These segments may encode simple
routing instructions for forwarding packets along a specific network routing instructions for forwarding packets along a specific network
path, but also steer them through Virtual Network Functions (VNFs) or path, but also steer them through Virtual Network Functions (VNFs) or
physical service appliances available in the network. physical service appliances available in the network.
In an SR network, each of these services, running either on a In an SR network, each of these services, running either on a
physical appliance or in a virtual environment, are associated with a physical appliance or in a virtual environment, are associated with a
segment identifier (SID). These service SIDs are then leveraged as segment identifier (SID). These service SIDs are then leveraged as
part of a SID-list to steer packets through the corresponding part of a SID-list to steer packets through the corresponding
services. Service SIDs may be combined together in a SID-list to services. Service SIDs may be combined together in a SID-list to
achieve service programming, but also with other types of segments as achieve service programming, but also with other types of segments as
defined in [RFC8402]. SR thus provides a fully integrated solution defined in [RFC8402]. SR thus provides a fully integrated solution
for overlay, underlay and service programming. Furthermore, the IPv6 for overlay, underlay and service programming. Furthermore, the IPv6
instantiation of SR (SRv6) supports metadata transportation in the instantiation of SR (SRv6) [I-D.ietf-spring-srv6-network-programming]
Segment Routing header [I-D.ietf-6man-segment-routing-header], either supports metadata transportation in the Segment Routing Header
natively in the tag field or with extensions such as TLVs. [I-D.ietf-6man-segment-routing-header], either natively in the tag
field or with extensions such as TLVs.
This document describes how a service can be associated with a SID, This document describes how a service can be associated with a SID,
including legacy services with no SR capabilities, and how these including legacy services with no SR capabilities, and how these
service SIDs are integrated within an SR policy. The definition of service SIDs are integrated within an SR policy. The definition of
an SR Policy and the traffic steering mechanisms are covered in an SR Policy and the traffic steering mechanisms are covered in
[I-D.ietf-spring-segment-routing-policy] and hence outside the scope [I-D.ietf-spring-segment-routing-policy] and hence outside the scope
of this document. of this document.
The definition of control plane components, such as service segment The definition of control plane components, such as service segment
discovery, is outside the scope of this data plane document. For discovery, is outside the scope of this data plane document. For
reference, the option of using BGP extensions to support SR service reference, the option of using BGP extensions to support SR service
programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining]. programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining].
2. Terminology 2. Terminology
This document leverages the terminology proposed in [RFC8402] and This document leverages the terminology proposed in [RFC8402],
[RFC8660], [I-D.ietf-6man-segment-routing-header],
[I-D.ietf-spring-srv6-network-programming] and
[I-D.ietf-spring-segment-routing-policy]. It also introduces the [I-D.ietf-spring-segment-routing-policy]. It also introduces the
following new terms. following new terms.
Service segment: A segment associated with a service. The service Service segment: A segment associated with a service. The service
may either run on a physical appliance or in a virtual environment may either run on a physical appliance or in a virtual environment
such as a virtual machine or container. such as a virtual machine or container.
SR-aware service: A service that is fully capable of processing SR SR-aware service: A service that is fully capable of processing SR
traffic. An SR-aware service can be directly associated with a traffic. An SR-aware service can be directly associated with a
service segment. service segment.
SR-unaware service: A service that is unable to process SR traffic or SR-unaware service: A service that is unable to process SR traffic or
may behave incorrectly due to presence of SR information in the may behave incorrectly due to presence of SR information in the
packet headers. An SR-unaware service can be associated with a packet headers. An SR-unaware service can be associated with a
service segment through an SR proxy function. service segment through an SR proxy function.
3. Classification and steering 3. Classification and Steering
Classification and steering mechanisms are defined in section 8 of Classification and steering mechanisms are defined in section 8 of
[I-D.ietf-spring-segment-routing-policy] and are independent from the [I-D.ietf-spring-segment-routing-policy] and are independent from the
purpose of the SR policy. From the perspective of a headend node purpose of the SR policy. From the perspective of a headend node
classifying and steering traffic into an SR policy, there is no classifying and steering traffic into an SR policy, there is no
difference whether this policy contains IGP, BGP, peering, VPN or difference whether this policy contains IGP, BGP, peering, VPN or
service segments, or any combination of these. service segments, or any combination of these.
As documented in the above reference, traffic is classified when As documented in the above reference, traffic is classified when
entering an SR domain. The SR policy headend may, depending on its entering an SR domain. The SR policy headend may, depending on its
skipping to change at page 5, line 5 skipping to change at page 5, line 5
classify packets sharing the same set of properties. Classified classify packets sharing the same set of properties. Classified
traffic is then steered into the appropriate SR policy and forwarded traffic is then steered into the appropriate SR policy and forwarded
as per the SID-list(s) of the active candidate path. as per the SID-list(s) of the active candidate path.
SR traffic can be re-classified by an SR endpoint along the original SR traffic can be re-classified by an SR endpoint along the original
SR policy (e.g., DPI service) or a transit node intercepting the SR policy (e.g., DPI service) or a transit node intercepting the
traffic. This node is the head-end of a new SR policy that is traffic. This node is the head-end of a new SR policy that is
imposed onto the packet, either as a stack of MPLS labels or as an imposed onto the packet, either as a stack of MPLS labels or as an
IPv6 SRH. IPv6 SRH.
4. Service segments 4. Service Segments
In the context of this document, the term service refers to a In the context of this document, the term service refers to a
physical appliance running on dedicated hardware, a virtualized physical appliance running on dedicated hardware, a virtualized
service inside an isolated environment such as a Virtual Machine service inside an isolated environment such as a Virtual Machine
(VM), container or namespace, or any process running on a compute (VM), container or namespace, or any process running on a compute
element. A service may also comprise multiple sub-components running element. A service may also comprise multiple sub-components running
in different processes or containers. Unless otherwise stated, this in different processes or containers. Unless otherwise stated, this
document does not make any assumption on the type or execution document does not make any assumption on the type or execution
environment of a service. environment of a service.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
by assigning a segment identifier, or SID, to the service and by assigning a segment identifier, or SID, to the service and
including this service SID in the SR policy SID-list. Such a service including this service SID in the SR policy SID-list. Such a service
SID may be of local or global significance. In the former case, SID may be of local or global significance. In the former case,
other segments, such as prefix or adjacency segments, can be used to other segments, such as prefix or adjacency segments, can be used to
steer the traffic up to the node where the service segment is steer the traffic up to the node where the service segment is
instantiated. In the latter case, the service is directly reachable instantiated. In the latter case, the service is directly reachable
from anywhere in the routing domain. This is realized with SR-MPLS from anywhere in the routing domain. This is realized with SR-MPLS
by assigning a SID from the global label block by assigning a SID from the global label block
([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising
the SID locator in the routing protocol the SID locator in the routing protocol
([I-D.filsfils-spring-srv6-network-programming]). It is up to the ([I-D.ietf-spring-srv6-network-programming]). It is up to the
network operator to define the scope and reachability of each service network operator to define the scope and reachability of each service
SID. This decision can be based on various considerations such as SID. This decision can be based on various considerations such as
infrastructure dynamicity, available control plane or orchestration infrastructure dynamicity, available control plane or orchestration
system capabilities. system capabilities.
This document categorizes services in two types, depending on whether This document categorizes services in two types, depending on whether
they are able to behave properly in the presence of SR information or they are able to behave properly in the presence of SR information or
not. These are respectively named SR-aware and SR-unaware services. not. These are respectively named SR-aware and SR-unaware services.
4.1. SR-aware services 4.1. SR-Aware Services
An SR-aware service can process the SR information in the packets it An SR-aware service can process the SR information in the packets it
receives. This means being able to identify the active segment as a receives. This means being able to identify the active segment as a
local instruction and move forward in the segment list, but also that local instruction and move forward in the segment list, but also that
the service's own behavior is not hindered due to the presence of SR the service's own behavior is not hindered due to the presence of SR
information. For example, an SR-aware firewall filtering SRv6 information. For example, an SR-aware firewall filtering SRv6
traffic based on its final destination must retrieve that information traffic based on its final destination must retrieve that information
from the last entry in the SRH rather than the Destination Address from the last entry in the SRH rather than the Destination Address
field of the IPv6 header. field of the IPv6 header.
An SR-aware service is associated with a locally instantiated service An SR-aware service is associated with a locally instantiated service
segment, which is used to steer traffic through it. segment, which is used to steer traffic through it.
If the service is configured to intercept all the packets passing If the service is configured to intercept all the packets passing
through the appliance, the underlying routing system only has to through the appliance, the underlying routing system only has to
implement a default SR endpoint behavior (SR-MPLS node segment or implement a default SR endpoint behavior (e.g., SR-MPLS node segment
SRv6 End function), and the corresponding SID will be used to steer or SRv6 End behavior), and the corresponding SID will be used to
traffic through the service. steer traffic through the service.
If the service requires the packets to be directed to a specific If the service requires the packets to be directed to a specific
virtual interface, networking queue or process, a dedicated SR virtual interface, networking queue or process, a dedicated SR
behavior may be required to steer the packets to the appropriate behavior may be required to steer the packets to the appropriate
location. The definition of such service-specific functions is out location. The definition of such service-specific functions is out
of the scope of this document. of the scope of this document.
SR-aware services also enable advanced network programming SR-aware services also enable advanced network programming
functionalities such as conditional branching and jumping to functionalities such as conditional branching and jumping to
arbitrary SIDs in the segment list. In addition, SRv6 provides arbitrary SIDs in the segment list. In addition, SRv6 provides
several ways of passing and exchanging information between services several ways of passing and exchanging information between services
(e.g., SID arguments, tag field and TLVs). An example scenario (e.g., SID arguments, tag field and TLVs). An example scenario
involving these features is described in [IFIP18], which discusses involving these features is described in [IFIP18], which discusses
the implementation of an SR-aware Intrusion Detection System. the implementation of an SR-aware Intrusion Detection System.
Examples of SR-aware services are provided in section Section 8.1. Examples of SR-aware services are provided in section Section 8.1.
4.2. SR-unaware services 4.2. SR-Unaware Services
Any service that does not meet the above criteria for SR-awareness is Any service that does not meet the above criteria for SR-awareness is
considered as SR-unaware. considered as SR-unaware.
An SR-unaware service is not able to process the SR information in An SR-unaware service is not able to process the SR information in
the traffic that it receives. It may either drop the traffic or take the traffic that it receives. It may either drop the traffic or take
erroneous decisions due to the unrecognized routing information. In erroneous decisions due to the unrecognized routing information. In
order to include such services in an SR policy, it is thus required order to include such services in an SR policy, it is thus required
to remove the SR information as well as any other encapsulation to remove the SR information as well as any other encapsulation
header before the service receives the packet, or to alter it in such header before the service receives the packet, or to alter it in such
skipping to change at page 7, line 5 skipping to change at page 7, line 5
handle the SR processing on behalf of a service. The SR proxy can handle the SR processing on behalf of a service. The SR proxy can
run as a separate process on the service appliance, on a virtual run as a separate process on the service appliance, on a virtual
switch or router on the compute node or on a different host. switch or router on the compute node or on a different host.
An SR-unaware service is associated with a service segment An SR-unaware service is associated with a service segment
instantiated on the SR proxy, which is used to steer traffic through instantiated on the SR proxy, which is used to steer traffic through
the service. Section 6 describes several SR proxy behaviors to the service. Section 6 describes several SR proxy behaviors to
handle the encapsulation headers and SR information under various handle the encapsulation headers and SR information under various
circumstances. circumstances.
5. SR service policies 5. SR Service Policies
An SR service policy is an SR policy, as defined in An SR service policy is an SR policy, as defined in
[I-D.ietf-spring-segment-routing-policy], that includes at least one [I-D.ietf-spring-segment-routing-policy], that includes at least one
service. This service is represented in the SID-list by its service. This service is represented in the SID-list by its
associated service SID. In case the policy should include several associated service SID. In case the policy should include several
services, the service traversal order is indicated by the relative services, the service traversal order is indicated by the relative
position of each service SID in the SID-list. Using the mechanisms position of each service SID in the SID-list. Using the mechanisms
described in [I-D.ietf-spring-segment-routing-policy], it is possible described in [I-D.ietf-spring-segment-routing-policy], it is possible
to load balance the traffic over several services, or instances of to load balance the traffic over several services, or instances of
the same service, by associating with the SR service policy a the same service, by associating with the SR service policy a
skipping to change at page 8, line 30 skipping to change at page 8, line 30
This model applies regardless of the SR-awareness of the service. If This model applies regardless of the SR-awareness of the service. If
it is SR-unaware, then S simply represents the proxy that takes care it is SR-unaware, then S simply represents the proxy that takes care
of transmitting the packet to the actual service. of transmitting the packet to the actual service.
Traffic can then be steered into this policy using any of the Traffic can then be steered into this policy using any of the
mechanisms described in [I-D.ietf-spring-segment-routing-policy]. mechanisms described in [I-D.ietf-spring-segment-routing-policy].
The following subsections describe the specificities of each SR The following subsections describe the specificities of each SR
dataplane. dataplane.
5.1. SR-MPLS data plane 5.1. SR-MPLS Data Plane
+-----------------------------------------------+ +-----------------------------------------------+
| SR-MPLS network | | SR-MPLS network |
| | | |
+----+----+ ------> +---------+ ------> +----+-----+ +----+----+ ------> +---------+ ------> +----+-----+
| H +-------------+ S +-------------+ E | | H +-------------+ S +-------------+ E |
|(headend)| |(service)| |(endpoint)| |(headend)| |(service)| |(endpoint)|
+----+----+ +---------+ +----+-----+ +----+----+ +---------+ +----+-----+
| (1) (2) (3) (4) | | (1) (2) (3) (4) |
|+---------+ +---------+ +---------+ +---------+| |+---------+ +---------+ +---------+ +---------+|
|| ... | | L(S) | | ... | | L(E) || || ... | | L(S) | | ... | | L(E) ||
skipping to change at page 9, line 36 skipping to change at page 9, line 36
In an SR-MPLS network, the SR policy SID-list is encoded as a stack In an SR-MPLS network, the SR policy SID-list is encoded as a stack
of MPLS labels[I-D.ietf-spring-segment-routing-mpls] and pushed on of MPLS labels[I-D.ietf-spring-segment-routing-mpls] and pushed on
top of the packet. top of the packet.
In the example shown on Figure 2, the SR policy should steer the In the example shown on Figure 2, the SR policy should steer the
traffic from the head-end H to the endpoint E via a service S. This traffic from the head-end H to the endpoint E via a service S. This
translates into an MPLS label stack that includes at least a label translates into an MPLS label stack that includes at least a label
L(S) associated to service S and a label L(E) associated to the L(S) associated to service S and a label L(E) associated to the
endpoint E. The label stack may also include additional intermediate endpoint E. The label stack may also include additional intermediate
segments if these are required for traffic engineering (e.g., to SIDs if these are required for traffic engineering (e.g., to encode a
encode a low latency path between H and S and / or between S and E) low latency path between H and S and / or between S and E) or simply
or simply for reachability purposes. Indeed, the service SID L(S) for reachability purposes. Indeed, the service SID L(S) may be taken
may be taken from the global or local SID block of node S and, in the from the global or local SID block of node S and, in the latter case,
latter case, one or more SIDs might be needed before L(S) in order one or more SIDs might be needed before L(S) in order for the packet
for the packet to reach node S (e.g., a prefix-SID of S), where L(S) to reach node S (e.g., a prefix-SID of S), where L(S) can be
can be interpreted. The same applies for the segment L(E) at the SR interpreted. The same applies for the SID L(E) at the SR policy
policy endpoint. endpoint.
Special consideration must be taken into account when using Local Special consideration must be taken into account when using Local
SIDs for service identification due to increased label stack depth SIDs for service identification due to increased label stack depth
and the associated impacts. and the associated impacts.
When the packet arrives at S, this node determines the MPLS payload When the packet arrives at S, this node determines the MPLS payload
type and the appropriate behavior for processing the packet based on type and the appropriate behavior for processing the packet based on
the semantic locally associated to the top label L(S). If S is an the semantic locally associated to the top label L(S). If S is an
SR-aware service, the SID L(S) may provide additional context or SR-aware service, the SID L(S) may provide additional context or
indication on how to process the packet (e.g., a firewall SID may indication on how to process the packet (e.g., a firewall SID may
indicate which rule set should be applied onto the packet). If S is indicate which rule set should be applied onto the packet). If S is
a proxy in front of an SR-unaware service, L(S) indicates how and to a proxy in front of an SR-unaware service, L(S) indicates how and to
which service attached to this proxy the packet should be which service attached to this proxy the packet should be
transmitted. At some point in the process, L(S) is also popped from transmitted. At some point in the process, L(S) is also popped from
the label stack in order to expose the next SID, which may be L(E) or the label stack in order to expose the next SID, which may be L(E) or
another intermediate segment. another intermediate SID.
5.2. SRv6 data plane 5.2. SRv6 Data Plane
+-----------------------------------------------+ +-----------------------------------------------+
| SRv6 network | | SRv6 network |
| | | |
+----+----+ ------> +---------+ ------> +----+-----+ +----+----+ ------> +---------+ ------> +----+-----+
| H +-------------+ S +-------------+ E | | H +-------------+ S +-------------+ E |
|(headend)| |(service)| |(endpoint)| |(headend)| |(service)| |(endpoint)|
+----+----+ +---------+ +----+-----+ +----+----+ +---------+ +----+-----+
| (1) (2) (3) (4) | | (1) (2) (3) (4) |
|+---------+ +---------+ +---------+ +---------+| |+---------+ +---------+ +---------+ +---------+|
skipping to change at page 10, line 37 skipping to change at page 10, line 37
|| S,..;| | S,..;| | S,..;| | S,..;|| || S,..;| | S,..;| | S,..;| | S,..;||
|| SL=i)| | SL=j)| | SL=k)| | SL=0)|| || SL=i)| | SL=j)| | SL=k)| | SL=0)||
|+---------+ +---------+ +---------+ +---------+| |+---------+ +---------+ +---------+ +---------+|
||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt|| ||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt||
|+---------+ +---------+ +---------+ +---------+| |+---------+ +---------+ +---------+ +---------+|
+-----------------------------------------------+ +-----------------------------------------------+
Figure 3: Packet walk in an SRv6 network Figure 3: Packet walk in an SRv6 network
In an SRv6 network, the SR Policy is encoded into the packet as an In an SRv6 network, the SR Policy is encoded into the packet as an
IPv6 header possibly followed by a Segment Routing header (SRH) IPv6 header possibly followed by a Segment Routing Header (SRH)
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
In the example shown on Figure 3, the SR policy should steer the In the example shown on Figure 3, the SR policy should steer the
traffic from the head-end H to the endpoint E via a service S. This traffic from the head-end H to the endpoint E via a service S. This
translates into an SRH that includes at least a segment SID(S) to the translates into Segment-List that includes at least a segment SID(S)
service, or service proxy, S and a segment SID(E) to the endpoint E. to the service, or service proxy, S and a segment SID(E) to the
The SRH may also include additional intermediate segments if these endpoint E. The Segment-List may also include additional
are required for traffic engineering (e.g., the encode a low latency intermediate SIDs if these are required for traffic engineering
path between H and S and / or between S and E) or simply for (e.g., the encode a low latency path between H and S and / or between
reachability purposes. Indeed, the service segment locator may or S and E) or simply for reachability purposes. Indeed, the service
may not be advertised in the routing protocol and, in the latter SID locator may or may not be advertised in the routing protocol and,
case, one or more SIDs might be needed before SID(S) in order to in the latter case, one or more SIDs might be needed before SID(S) in
bring the packet up to node S, where SID(S) can be interpreted. The order to bring the packet up to node S, where SID(S) can be
same applies for the segment SID(E) at the SR policy endpoint. interpreted. The same applies for the segment SID(E) at the SR
policy endpoint.
When the packet arrives at S, this node determines how to process the When the packet arrives at S, this node determines how to process the
packet based on the semantic locally associated to the active segment packet based on the semantic locally associated to the active segment
SID(S). If S is an SR-aware service, then SID(S) may provide SID(S). If S is an SR-aware service, then SID(S) may provide
additional context or indication on how to process the packet (e.g., additional context or indication on how to process the packet (e.g.,
a firewall SID may indicate which rule set should be applied onto the a firewall SID may indicate which rule set should be applied onto the
packet). If S is a proxy in front of an SR-unaware service, SID(S) packet). If S is a proxy in front of an SR-unaware service, SID(S)
indicates how and to which service attached to this proxy the packet indicates how and to which service attached to this proxy the packet
should be transmitted. At some point in the process, the SRv6 End should be transmitted. At some point in the process, the SRv6 End
function is also applied in order to make the next SID, which may be function is also applied in order to make the next SID, which may be
SID(E) or another intermediate segment, active. SID(E) or another intermediate SID, active.
The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be
an encapsulated IP packet, an Ethernet frame or a transport-layer an encapsulated IP packet, an Ethernet frame or a transport-layer
payload, for example. payload, for example.
6. SR proxy behaviors 6. SR Proxy Behaviors
This section describes several SR proxy behaviors designed to enable This section describes several SR proxy behaviors designed to enable
SR service programming through SR-unaware services. A system SR service programming through SR-unaware services. A system
implementing one of these functions may handle the SR processing on implementing one of these behaviors may handle the SR processing on
behalf of an SR-unaware service and allows the service to properly behalf of an SR-unaware service and allows the service to properly
process the traffic that is steered through it. process the traffic that is steered through it.
A service may be located at any hop in an SR policy, including the A service may be located at any hop in an SR policy, including the
last segment. However, the SR proxy behaviors defined in this last segment. However, the SR proxy behaviors defined in this
section are dedicated to supporting SR-unaware services at section are dedicated to supporting SR-unaware services at
intermediate hops in the segment list. In case an SR-unaware service intermediate hops in the segment list. In case an SR-unaware service
is at the last segment, it is sufficient to ensure that the SR is at the last segment, it is sufficient to ensure that the SR
information is ignored (IPv6 routing extension header with Segments information is ignored (IPv6 routing extension header with Segments
Left equal to 0) or removed before the packet reaches the service Left equal to 0) or removed before the packet reaches the service
(MPLS PHP, SRv6 End.D or PSP). (MPLS PHP, SRv6 decapsulation behavior or PSP flavor).
As illustrated on Figure 4, the generic behavior of an SR proxy has As illustrated on Figure 4, the generic behavior of an SR proxy has
two parts. The first part is in charge of passing traffic from the two parts. The first part is in charge of passing traffic from the
network to the service. It intercepts the SR traffic destined for network to the service. It intercepts the SR traffic destined for
the service via a locally instantiated service segment, modifies it the service via a locally instantiated service segment, modifies it
in such a way that it appears as non-SR traffic to the service, then in such a way that it appears as non-SR traffic to the service, then
sends it out on a given interface, IFACE-OUT, connected to the sends it out on a given interface, IFACE-OUT, connected to the
service. The second part receives the traffic coming back from the service. The second part receives the traffic coming back from the
service on IFACE-IN, restores the SR information and forwards it service on IFACE-IN, restores the SR information and forwards it
according to the next segment in the list. IFACE-OUT and IFACE-IN according to the next segment in the list. IFACE-OUT and IFACE-IN
skipping to change at page 13, line 21 skipping to change at page 13, line 21
| | D | e | e | | | D | e | e |
| S | y | d | r | | S | y | d | r |
| t | n | | a | | t | n | | a |
| a | a | m | d | | a | a | m | d |
| t | m | e | i | | t | m | e | i |
| i | i | m | n | | i | i | m | n |
| c | c | . | g | | c | c | . | g |
+---------------------------------------+-----+-----+-----+-----+ +---------------------------------------+-----+-----+-----+-----+
| | SR-MPLS | Y | Y | Y | - | | | SR-MPLS | Y | Y | Y | - |
| | | | | | | | | | | | | |
| SR flavors | SRv6 insertion | P | P | P | Y | | SR flavors | Inline SRv6 | P | P | P | Y |
| | | | | | | | | | | | | |
| | SRv6 encapsulation | Y | Y | Y | - | | | SRv6 encapsulation | Y | Y | Y | - |
+----------------+----------------------+-----+-----+-----+-----+ +----------------+----------------------+-----+-----+-----+-----+
| Chain agnostic configuration | N | N | Y | Y | | Chain agnostic configuration | N | N | Y | Y |
+---------------------------------------+-----+-----+-----+-----+ +---------------------------------------+-----+-----+-----+-----+
| Transparent to chain changes | N | Y | Y | Y | | Transparent to chain changes | N | Y | Y | Y |
+----------------+----------------------+-----+-----+-----+-----+ +----------------+----------------------+-----+-----+-----+-----+
| | DA modification | Y | Y | Y | NAT | | | DA modification | Y | Y | Y | NAT |
| | | | | | | | | | | | | |
| | Payload modification | Y | Y | Y | Y | | | Payload modification | Y | Y | Y | Y |
| | | | | | | | | | | | | |
|Service support | Packet generation | Y | Y |cache|cache| |Service support | Packet generation | Y | Y |cache|cache|
| | | | | | | | | | | | | |
| | Packet deletion | Y | Y | Y | Y | | | Packet deletion | Y | Y | Y | Y |
| | | | | | | | | | | | | |
| | Packet re-ordering | Y | Y | Y | Y |
| | | | | | |
| | Transport endpoint | Y | Y |cache|cache| | | Transport endpoint | Y | Y |cache|cache|
+----------------+----------------------+-----+-----+-----+-----+ +----------------+----------------------+-----+-----+-----+-----+
| | Ethernet | Y | Y | Y | - | | | Ethernet | Y | Y | Y | - |
| Supported | | | | | | | Supported | | | | | |
| traffic | IPv4 | Y | Y | Y | - | | traffic | IPv4 | Y | Y | Y | - |
| | | | | | | | | | | | | |
| | IPv6 | Y | Y | Y | Y | | | IPv6 | Y | Y | Y | Y |
+----------------+----------------------+-----+-----+-----+-----+ +----------------+----------------------+-----+-----+-----+-----+
Figure 5: SR proxy summary Figure 5: SR proxy summary
Note: The use of a shared memory proxy requires both the service Note: The use of a shared memory proxy requires both the service
(VNF) and the proxy to be running on the same node. (VNF) and the proxy to be running on the same node.
6.1. Static SR proxy 6.1. Static SR Proxy
The static proxy is an SR endpoint behavior for processing SR-MPLS or The static proxy is an SR endpoint behavior for processing SR-MPLS or
SRv6 encapsulated traffic on behalf of an SR-unaware service. This SRv6 encapsulated traffic on behalf of an SR-unaware service. This
proxy thus receives SR traffic that is formed of an MPLS label stack proxy thus receives SR traffic that is formed of an MPLS label stack
or an IPv6 header on top of an inner packet, which can be Ethernet, or an IPv6 header on top of an inner packet, which can be Ethernet,
IPv4 or IPv6. IPv4 or IPv6.
A static SR proxy segment is associated with the following mandatory A static SR proxy segment is associated with the following mandatory
parameters parameters
skipping to change at page 16, line 5 skipping to change at page 16, line 5
through "bump in the wire" services that are transparent to the IP through "bump in the wire" services that are transparent to the IP
and Ethernet layers. This type of processing is assumed when the and Ethernet layers. This type of processing is assumed when the
inner traffic type is Ethernet, since the original destination inner traffic type is Ethernet, since the original destination
address of the Ethernet frame is preserved when the packet is steered address of the Ethernet frame is preserved when the packet is steered
into the SR Policy and likely associated with a node downstream of into the SR Policy and likely associated with a node downstream of
the policy tail-end. In case the inner type is IP (IPv4 or IPv6), the policy tail-end. In case the inner type is IP (IPv4 or IPv6),
the NH-ADDR parameter may be set to a dummy or broadcast Ethernet the NH-ADDR parameter may be set to a dummy or broadcast Ethernet
address, or simply to the address of the proxy receiving interface address, or simply to the address of the proxy receiving interface
(IFACE-IN). (IFACE-IN).
6.1.1. SR-MPLS pseudocode 6.1.1. SR-MPLS Pseudocode
6.1.1.1. Static proxy for inner type Ethernet 6.1.1.1. Static Proxy for Inner Type Ethernet
Upon receiving an MPLS packet with top label L, where L is an MPLS L2 When processing an MPLS packet whose top label matches a locally
static proxy segment, a node N does: instantiated MPLS static proxy SID for Ethernet traffic, the
following pseudocode is executed.
1. Pop all labels S01. POP all labels in the MPLS label stack.
2. IF payload type is Ethernet THEN S02. Submit the frame to the Ethernet module for transmission via
3. Forward the exposed frame on IFACE-OUT interface IFACE-OUT.
4. ELSE
5. Drop the packet
Upon receiving on IFACE-IN an Ethernet frame with a destination Figure 6: SID processing for MPLS static proxy (Ethernet)
address different than the interface address, a node N does:
1. Push labels in CACHE on top of the frame Ethernet header When processing an Ethernet frame received on the interface IFACE-IN
2. Lookup the top label and proceed accordingly and with a destination MAC address that is neither a broadcast
address nor matches the address of IFACE-IN, the following pseudocode
is executed.
The receiving interface must be configured in promiscuous mode in S01. Retrieve the CACHE entry associated with IFACE-IN.
order to accept those Ethernet frames. S02. If the CACHE entry is not empty {
S03. Remove the preamble or Frame Check Sequence (FCS).
S04. PUSH all labels from the retrieved CACHE entry.
S05. Submit the packet to the MPLS module for transmission as per
the top label in the MPLS label stack.
S06. }
6.1.1.2. Static proxy for inner type IPv4 Figure 7: Inbound policy for MPLS static proxy (Ethernet)
Upon receiving an MPLS packet with top label L, where L is an MPLS 6.1.1.2. Static Proxy for Inner Type IPv4
IPv4 static proxy segment, a node N does:
1. Pop all labels When processing an MPLS packet whose top label matches a locally
2. IF payload type is IPv4 THEN instantiated MPLS static proxy SID for IPv4 traffic, the following
3. Forward the exposed packet on IFACE-OUT towards NH-ADDR pseudocode is executed.
4. ELSE
5. Drop the packet
Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N S01. POP all labels in the MPLS label stack.
does: S02. Submit the packet to the IPv4 module for transmission on
interface IFACE-OUT via NH-ADDR.
1. Decrement TTL and update checksum Figure 8: SID processing for MPLS static proxy (IPv4)
2. Push labels in CACHE on top of the packet IPv4 header
3. Lookup the top label and proceed accordingly
6.1.1.3. Static proxy for inner type IPv6 When processing an IPv4 packet received on the interface IFACE-IN and
with a destination address that does not match any address of IFACE-
IN, the following pseudocode is executed.
Upon receiving an MPLS packet with top label L, where L is an MPLS S01. Retrieve the CACHE entry associated with IFACE-IN.
IPv6 static proxy segment, a node N does: S02. If the CACHE entry is not empty {
S03. Decrement the TTL and adjust the checksum accordingly.
S04. PUSH all labels from the retrieved CACHE entry.
S05. Submit the packet to the MPLS module for transmission as per
the top label in the MPLS label stack.
S06. }
1. Pop all labels Figure 9: Inbound policy for MPLS static proxy (IPv4)
2. IF payload type is IPv6 THEN
3. Forward the exposed packet on IFACE-OUT towards NH-ADDR
4. ELSE
5. Drop the packet
Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 6.1.1.3. Static Proxy for Inner Type IPv6
does:
1. Decrement Hop Limit When processing an MPLS packet whose top label matches a locally
2. Push labels in CACHE on top of the packet IPv6 header instantiated MPLS static proxy SID for IPv6 traffic, the following
3. Lookup the top label and proceed accordingly pseudocode is executed.
6.1.2. SRv6 pseudocode S01. POP all labels in the MPLS label stack.
S02. Submit the packet to the IPv6 module for transmission on
interface IFACE-OUT via NH-ADDR.
6.1.2.1. Static proxy for inner type Ethernet Figure 10: SID processing for MPLS static proxy (IPv6)
Upon receiving an IPv6 packet destined for S, where S is an IPv6 When processing an IPv6 packet received on the interface IFACE-IN and
static proxy segment for Ethernet traffic, a node N does: with a destination address that does not match any address of IFACE-
IN, the following pseudocode is executed.
1. IF ENH == 59 THEN ;; Ref1 S01. Retrieve the CACHE entry associated with IFACE-IN.
2. Remove the (outer) IPv6 header and its extension headers S02. If the CACHE entry is not empty {
3. Forward the exposed frame on IFACE-OUT S03. Decrement the Hop Limit.
4. ELSE S04. PUSH all labels from the retrieved CACHE entry.
5. Drop the packet S05. Submit the packet to the MPLS module for transmission as per
the top label in the MPLS label stack.
S06. }
Ref1: 59 refers to "no next header" as defined by IANA allocation for Figure 11: Inbound policy for MPLS static proxy (IPv6)
Internet Protocol Numbers.
Upon receiving on IFACE-IN an Ethernet frame with a destination 6.1.2. SRv6 Pseudocode
address different than the interface address, a node N does:
1. Retrieve CACHE entry matching IFACE-IN and traffic type 6.1.2.1. Static Proxy for Inner Type Ethernet
2. Push SRH with CACHE.LIST on top of the Ethernet header ;; Ref2
3. Push IPv6 header with
SA = CACHE.SA
DA = CACHE.LIST[0] ;; Ref3
Next Header = 43 ;; Ref4
4. Set outer payload length and flow label
5. Lookup outer DA in appropriate table and proceed accordingly
Ref2: Unless otherwise specified, the segments in CACHE.LIST should When processing an IPv6 packet matching a FIB entry locally
be encoded in reversed order, Segment Left and Last Entry values instantiated as an SRv6 static proxy SID for Ethernet traffic, the
should be set of the length of CACHE.LIST minus 1, and Next Header following pseudocode is executed.
should be set to 59.
Ref3: CACHE.LIST[0] represents the first IPv6 SID in CACHE.LIST. S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Proceed to process the next header in the packet.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S07. }
S08. max_last_entry = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_last_entry) or
(Segments Left > (Last Entry + 1))) {
S10. Send an ICMP Parameter Problem message to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
Interrupt packet processing and discard the packet.
S11. }
S12. Decrement Hop Limit by 1.
S13. Decrement Segments Left by 1.
S14. Copy Segment List[Segments Left] from the SRH to the
Destination Address of the IPv6 header.
S15. If (Upper-layer header type != 143 (Ethernet)) {
S16. Resubmit the packet to the IPv6 module for transmission to
the new destination.
S17. }
S18. Perform IPv6 decapsulation.
S19. Submit the frame to the Ethernet module for transmission via
interface IFACE-OUT.
S20. }
Ref4: If CACHE.LIST contains a single entry, the SRH can be omitted Figure 12: SID processing for SRv6 static proxy (Ethernet)
and the Next Header value must be set to 59.
The receiving interface must be configured in promiscuous mode in S15: 143 (Ethernet) refers to the value assigned by IANA for
order to accept those Ethernet frames. "Ethernet" in the "Internet Protocol Numbers" registry.
6.1.2.2. Static proxy for inner type IPv4 When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 static proxy SID for Ethernet
traffic, the following pseudocode is executed.
Upon receiving an IPv6 packet destined for S, where S is an IPv6 S01. If (Upper-layer header type != 143 (Ethernet)) {
static proxy segment for IPv4 traffic, a node N does: S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1
S03. }
S04. Perform IPv6 decapsulation.
S05. Submit the frame to the Ethernet module for transmission via
interface IFACE-OUT.
1. IF ENH == 4 THEN ;; Ref1 Figure 13: Upper-layer header processing for SRv6 static proxy
2. Remove the (outer) IPv6 header and its extension headers (Ethernet)
3. Forward the exposed packet on IFACE-OUT towards NH-ADDR
4. ELSE
5. Drop the packet
Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation When processing an Ethernet frame received on the interface IFACE-IN
for Internet Protocol Numbers. and with a destination MAC address that is neither a broadcast
address nor matches the address of IFACE-IN, the following pseudocode
is executed.
Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N S01. Retrieve the CACHE entry associated with IFACE-IN.
does: S02. If the CACHE entry is not empty {
S03. Remove the preamble or Frame Check Sequence (FCS).
S04. Perform IPv6 encapsulation with an SRH
Source Address of the IPv6 header is set to CACHE.SA,
Destination Address of the IPv6 header is set to
CACHE.LIST[0],
Next Header of the SRH is set to 143 (Ethernet),
Segment List of the SRH is set to CACHE.LIST.
S05. Submit the packet to the IPv6 module for transmission to the
next destination.
S06. }
1. Decrement TTL and update checksum Figure 14: Inbound policy for SRv6 static proxy (Ethernet)
2. IF CACHE.SRH THEN ;; Ref2
3. Push CACHE.SRH on top of the existing IPv4 header
4. Set NH value of the pushed SRH to 4
5. Push outer IPv6 header with SA, DA and traffic class from CACHE
6. Set outer payload length and flow label
7. Set NH value to 43 if an SRH was added, or 4 otherwise
8. Lookup outer DA in appropriate table and proceed accordingly
Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless
static SR proxy segment associated with IFACE-IN. a local configuration indicates otherwise, the SIDs in CACHE.LIST
should be encoded in the Segment List field in reversed order, the
Segment Left and Last Entry values should be set of the length of
CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH
can be omitted and the Next Header field of the IPv6 header set to
143 (Ethernet).
6.1.2.3. Static proxy for inner type IPv6 6.1.2.2. Static Proxy for Inner Type IPv4
Upon receiving an IPv6 packet destined for S, where S is an IPv6 When processing an IPv6 packet matching a FIB entry locally
static proxy segment for IPv6 traffic, a node N does: instantiated as an SRv6 static proxy SID for IPv4 traffic, the
following pseudocode is executed.
1. IF ENH == 41 THEN ;; Ref1 S01. When an SRH is processed {
2. Remove the (outer) IPv6 header and its extension headers S02. If (Segments Left == 0) {
3. Forward the exposed packet on IFACE-OUT towards NH-ADDR S03. Proceed to process the next header in the packet.
4. ELSE S04. }
5. Drop the packet S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S07. }
S08. max_last_entry = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_last_entry) or
(Segments Left > (Last Entry + 1))) {
S10. Send an ICMP Parameter Problem message to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
Interrupt packet processing and discard the packet.
S11. }
S12. Decrement Hop Limit by 1.
S13. Decrement Segments Left by 1.
S14. Copy Segment List[Segments Left] from the SRH to the
Destination Address of the IPv6 header.
S15. If (Upper-layer header type != 4 (IPv4)) {
S16. Resubmit the packet to the IPv6 module for transmission to
the new destination.
S17. }
S18. Perform IPv6 decapsulation.
S19. Submit the packet to the IPv4 module for transmission on
interface IFACE-OUT via NH-ADDR.
S20. }
Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation Figure 15: SID processing for SRv6 static proxy (IPv4)
for Internet Protocol Numbers.
Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N When processing the Upper-layer header of a packet matching a FIB
does: entry locally instantiated as an SRv6 static proxy SID for IPv4
traffic, the following pseudocode is executed.
1. Decrement Hop Limit S01. If (Upper-layer header type != 4 (IPv4)) {
2. IF CACHE.SRH THEN ;; Ref2 S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1
3. Push CACHE.SRH on top of the existing IPv6 header S03. }
4. Set NH value of the pushed SRH to 41 S04. Perform IPv6 decapsulation.
5. Push outer IPv6 header with SA, DA and traffic class from CACHE S05. Submit the packet to the IPv4 module for transmission on
6. Set outer payload length and flow label interface IFACE-OUT via NH-ADDR.
7. Set NH value to 43 if an SRH was added, or 41 otherwise
8. Lookup outer DA in appropriate table and proceed accordingly
Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the Figure 16: Upper-layer header processing for SRv6 static proxy (IPv4)
static SR proxy segment associated with IFACE-IN.
6.2. Dynamic SR proxy When processing an IPv4 packet received on the interface IFACE-IN and
with a destination address that does not match any address of IFACE-
IN, the following pseudocode is executed.
S01. Retrieve the CACHE entry associated with IFACE-IN.
S02. If the CACHE entry is not empty {
S03. Decrement the TTL and adjust the checksum accordingly.
S04. Perform IPv6 encapsulation with an SRH
Source Address of the IPv6 header is set to CACHE.SA,
Destination Address of the IPv6 header is set to
CACHE.LIST[0],
Next Header of the SRH is set to 4 (IPv4),
Segment List of the SRH is set to CACHE.LIST.
S05. Submit the packet to the IPv6 module for transmission to the
next destination.
S06. }
Figure 17: Inbound policy for SRv6 static proxy (IPv4)
S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless
a local configuration indicates otherwise, the SIDs in CACHE.LIST
should be encoded in the Segment List field in reversed order, the
Segment Left and Last Entry values should be set of the length of
CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH
can be omitted and the Next Header field of the IPv6 header set to 4
(IPv4).
6.1.2.3. Static Proxy for Inner Type IPv6
When processing an IPv6 packet matching a FIB entry locally
instantiated as an SRv6 static proxy SID for IPv6 traffic, the
following pseudocode is executed.
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Proceed to process the next header in the packet.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S07. }
S08. max_last_entry = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_last_entry) or
(Segments Left > (Last Entry + 1))) {
S10. Send an ICMP Parameter Problem message to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
Interrupt packet processing and discard the packet.
S11. }
S12. Decrement Hop Limit by 1.
S13. Decrement Segments Left by 1.
S14. Copy Segment List[Segments Left] from the SRH to the
Destination Address of the IPv6 header.
S15. If (Upper-layer header type != 41 (IPv6)) {
S16. Resubmit the packet to the IPv6 module for transmission to
the new destination.
S17. }
S18. Perform IPv6 decapsulation.
S19. Submit the packet to the IPv6 module for transmission on
interface IFACE-OUT via NH-ADDR.
S20. }
Figure 18: SID processing for SRv6 static proxy (IPv6)
When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an SRv6 static proxy SID for IPv6
traffic, the following pseudocode is executed.
S01. If (Upper-layer header type != 41 (IPv6)) {
S02. Process as per [I-D.ietf-spring-srv6-network-programming] Section 4.1.1
S03. }
S04. Perform IPv6 decapsulation.
S05. Submit the packet to the IPv6 module for transmission on
interface IFACE-OUT via NH-ADDR.
Figure 19: Upper-layer header processing for SRv6 static proxy (IPv6)
When processing an IPv6 packet received on the interface IFACE-IN and
with a destination address that does not match any address of IFACE-
IN, the following pseudocode is executed.
S01. Retrieve the CACHE entry associated with IFACE-IN.
S02. If the CACHE entry is not empty {
S03. Decrement the Hop Limit.
S04. Perform IPv6 encapsulation with an SRH
Source Address of the IPv6 header is set to CACHE.SA,
Destination Address of the IPv6 header is set to
CACHE.LIST[0],
Next Header of the SRH is set to 41 (IPv6),
Segment List of the SRH is set to CACHE.LIST.
S05. Submit the packet to the IPv6 module for transmission to the
next destination.
S06. }
Figure 20: Inbound policy for SRv6 static proxy (IPv6)
S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless
a local configuration indicates otherwise, the SIDs in CACHE.LIST
should be encoded in the Segment List field in reversed order, the
Segment Left and Last Entry values should be set of the length of
CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH
can be omitted and the Next Header field of the (outer) IPv6 header
set to 41 (IPv6).
6.2. Dynamic SR Proxy
The dynamic proxy is an improvement over the static proxy that The dynamic proxy is an improvement over the static proxy that
dynamically learns the SR information before removing it from the dynamically learns the SR information before removing it from the
incoming traffic. The same information can then be re-attached to incoming traffic. The same information can then be re-attached to
the traffic returning from the service. As opposed to the static SR the traffic returning from the service. As opposed to the static SR
proxy, no CACHE information needs to be configured. Instead, the proxy, no CACHE information needs to be configured. Instead, the
dynamic SR proxy relies on a local caching mechanism on the node dynamic SR proxy relies on a local caching mechanism on the node
instantiating this segment. instantiating this segment.
Upon receiving a packet whose active segment matches a dynamic SR Upon receiving a packet whose active segment matches a dynamic SR
skipping to change at page 19, line 45 skipping to change at page 24, line 5
information is then removed and the inner packet is sent towards the information is then removed and the inner packet is sent towards the
service. service.
The cache entry is not mapped to any particular packet, but instead The cache entry is not mapped to any particular packet, but instead
to an SR service policy identified by the receiving interface (IFACE- to an SR service policy identified by the receiving interface (IFACE-
IN). Any non-link-local IP packet or non-local Ethernet frame IN). Any non-link-local IP packet or non-local Ethernet frame
received on that interface will be re-encapsulated with the cached received on that interface will be re-encapsulated with the cached
headers as described in Section 6.1. The service may thus drop, headers as described in Section 6.1. The service may thus drop,
modify or generate new packets without affecting the proxy. modify or generate new packets without affecting the proxy.
6.2.1. SR-MPLS pseudocode 6.2.1. SR-MPLS Pseudocode
The dynamic proxy SR-MPLS pseudocode is obtained by inserting the The dynamic proxy SR-MPLS pseudocode is obtained by inserting the
following instructions at the beginning of the static SR-MPLS following instructions at the beginning of the static SR-MPLS
pseudocode (Section 6.1.1). pseudocode (Section 6.1.1).
1. IF top label S bit is 0 THEN ;; Ref1 S01. If the top label S bit is different from 0 {
2. Pop top label S02. Discard the packet.
3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref2 S03. }
4. Copy all remaining labels into C(IFACE-IN) ;; Ref3 S04. POP the top label.
5. ELSE S05. Copy the IPv6 encapsulation in a CACHE entry associated with the
6. Drop the packet interface IFACE-IN.
Ref1: As mentioned at the beginning of Section 6, an SR proxy is not Figure 21: SID processing for MPLS dynamic proxy
needed to include an SR-unaware service at the end of an SR policy.
Ref2: A TTL margin can be configured for the top label stack entry to S01: As mentioned at the beginning of Section 6, an SR proxy is not
prevent constant cache updates when multiple equal-cost paths with needed to include an SR-unaware service at the end of an SR policy.
different hop counts are used towards the SR proxy node. In that
case, a TTL difference smaller than the configured margin should not
trigger a cache update (provided that the labels are the same).
Ref3: C(IFACE-IN) represents the cache entry associated to the S05: An implementation may optimize the caching procedure by copying
dynamic SR proxy segment. It is identified with IFACE-IN in order to information into the cache only if it is different from the current
efficiently retrieve the right SR information when a packet arrives content of the cache entry. Furthermore, a TTL margin can be
on this interface. configured for the top label stack entry to prevent constant cache
updates when multiple equal-cost paths with different hop counts are
used towards the SR proxy node. In that case, a TTL difference
smaller than the configured margin should not trigger a cache update
(provided that the labels are the same).
In addition, the inbound policy should check that C(IFACE-IN) has When processing an Ethernet frame, an IPv4 packet or an IPv6 packet
been defined before attempting to restore the MPLS label stack and received on the interface IFACE-IN and with a destination address
drop the packet otherwise. that does not match any address of IFACE-IN, the pseudocode reported
in Figure 7, Figure 9 or Figure 11, respectively, is executed.
6.2.2. SRv6 pseudocode 6.2.2. SRv6 Pseudocode
The dynamic proxy SRv6 pseudocode is obtained by inserting the When processing an IPv6 packet matching a FIB entry locally
following instructions between lines 1 and 2 of the static proxy SRv6 instantiated as an SRv6 dynamic proxy SID, the same pseudocode as
pseudocode. described in Figure 12, Figure 15 and Figure 18, respectively for
Ethernet, IPv4 and IPv6 traffic, is executed with the following
addition between lines S17 and S18.
1. IF NH=SRH & SL > 0 THEN ;; Ref1 (... S17. })
2. Decrement SL and update the IPv6 DA with SRH[SL] S17.1. Copy the IPv6 encapsulation in a CACHE entry associated with
3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref2 the interface IFACE-IN.
4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref3 (S18. Perform IPv6 decapsulation...)
5. ELSE
6. Drop the packet
Ref1: As mentioned at the beginning of Section 6, an SR proxy is not Figure 22: SID processing for SRv6 dynamic proxy
needed to include an SR-unaware service at the end of an SR policy.
Ref2: "IPv6 encaps" represents the IPv6 header and any attached An implementation may optimize the caching procedure by copying
extension header. information into the cache only if it is different from the current
content of the cache entry. A Hop Limit margin can be configured to
prevent constant cache updates when multiple equal-cost paths with
different hop counts are used towards the SR proxy node. In that
case, a Hop Limit difference smaller than the configured margin
should not trigger a cache update. Similarly, the Flow Label value
can be ignored when comparing the current packet IPv6 header with the
cache entry. In this case, the Flow Label should be re-computed by
the proxy node when it restores the IPv6 encapsulation from the cache
entry.
Ref3: C(IFACE-IN) represents the cache entry associated to the When processing the Upper-layer header of a packet matching a FIB
dynamic SR proxy segment. It is identified with IFACE-IN in order to entry locally instantiated as an SRv6 dynamic proxy SID, process the
efficiently retrieve the right SR information when a packet arrives packet as per [I-D.ietf-spring-srv6-network-programming]
on this interface. Section 4.1.1.
In addition, the inbound policy should check that C(IFACE-IN) has When processing an Ethernet frame, an IPv4 packet or an IPv6 packet
been defined before attempting to restore the IPv6 encapsulation and received on the interface IFACE-IN and with a destination address
drop the packet otherwise. that does not match any address of IFACE-IN, the same pseudocode as
in Figure 14, Figure 17 or Figure 20, respectively, is executed.
6.3. Shared memory SR proxy 6.3. Shared Memory SR Proxy
The shared memory proxy is an SR endpoint behavior for processing SR- The shared memory proxy is an SR endpoint behavior for processing SR-
MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service.
This proxy behavior leverages a shared-memory interface with a This proxy behavior leverages a shared-memory interface with a
virtualized service (VNF) in order to hide the SR information from an virtualized service (VNF) in order to hide the SR information from an
SR-unaware service while keeping it attached to the packet. We SR-unaware service while keeping it attached to the packet. We
assume in this case that the proxy and the VNF are running on the assume in this case that the proxy and the VNF are running on the
same compute node. A typical scenario is an SR-capable vrouter same compute node. A typical scenario is an SR-capable vrouter
running on a container host and forwarding traffic to VNFs isolated running on a container host and forwarding traffic to VNFs isolated
within their respective container. within their respective container.
More details will be added in a future revision of this document. 6.4. Masquerading SR Proxy
6.4. Masquerading SR proxy
The masquerading proxy is an SR endpoint behavior for processing SRv6 The masquerading proxy is an SR endpoint behavior for processing SRv6
traffic on behalf of an SR-unaware service. This proxy thus receives traffic on behalf of an SR-unaware service. This proxy thus receives
SR traffic that is formed of an IPv6 header and an SRH on top of an SR traffic that is formed of an IPv6 header and an SRH on top of an
inner payload. The masquerading behavior is independent from the inner payload. The masquerading behavior is independent from the
inner payload type. Hence, the inner payload can be of any type but inner payload type. Hence, the inner payload can be of any type but
it is usually expected to be a transport layer packet, such as TCP or it is usually expected to be a transport layer packet, such as TCP or
UDP. UDP.
A masquerading SR proxy segment is associated with the following A masquerading SR proxy segment is associated with the following
mandatory parameters: mandatory parameters:
o S-ADDR: Ethernet or IPv6 address of the service o NH-ADDR: Next hop Ethernet address
o IFACE-OUT: Local interface for sending traffic towards the service o IFACE-OUT: Local interface for sending traffic towards the service
o IFACE-IN: Local interface receiving the traffic coming back from o IFACE-IN: Local interface receiving the traffic coming back from
the service the service
A masquerading SR proxy segment is thus defined for a specific A masquerading SR proxy segment is thus defined for a specific
service and bound to a pair of directed interfaces or sub-interfaces service and bound to a pair of directed interfaces or sub-interfaces
on the proxy. As opposed to the static and dynamic SR proxies, a on the proxy. As opposed to the static and dynamic SR proxies, a
masquerading segment can be present at the same time in any number of masquerading segment can be present at the same time in any number of
SR service policies and the same interfaces can be bound to multiple SR service policies and the same interfaces can be bound to multiple
masquerading proxy segments. The only restriction is that a masquerading proxy segments. The only restriction is that a
masquerading proxy segment cannot be the last segment in an SR masquerading proxy segment cannot be the last segment in an SR
service policy. service policy.
The first part of the masquerading behavior is triggered when the The first part of the masquerading behavior is triggered when the
proxy node receives an IPv6 packet whose Destination Address matches proxy node receives an IPv6 packet whose Destination Address matches
a masquerading proxy segment. The proxy inspects the IPv6 extension a masquerading proxy SID. The proxy inspects the IPv6 extension
headers and substitutes the Destination Address with the last segment headers and substitutes the Destination Address with the last SID in
in the SRH attached to the IPv6 header, which represents the final the SRH attached to the IPv6 header, which represents the final
destination of the IPv6 packet. The packet is then sent out towards destination of the IPv6 packet. The packet is then sent out towards
the service. the service.
The service receives an IPv6 packet whose source and destination The service receives an IPv6 packet whose source and destination
addresses are respectively the original source and final destination. addresses are respectively the original source and final destination.
It does not attempt to inspect the SRH, as RFC8200 specifies that It does not attempt to inspect the SRH, as RFC8200 specifies that
routing extension headers are not examined or processed by transit routing extension headers are not examined or processed by transit
nodes. Instead, the service simply forwards the packet based on its nodes. Instead, the service simply forwards the packet based on its
current Destination Address. In this scenario, we assume that the current Destination Address. In this scenario, we assume that the
service can only inspect, drop or perform limited changes to the service can only inspect, drop or perform limited changes to the
packets. For example, Intrusion Detection Systems, Deep Packet packets. For example, Intrusion Detection Systems, Deep Packet
Inspectors and non-NAT Firewalls are among the services that can be Inspectors and non-NAT Firewalls are among the services that can be
supported by a masquerading SR proxy. Variants of the masquerading supported by a masquerading SR proxy. Flavors of the masquerading
behavior are defined in Section 6.4.2 and Section 6.4.3 to support a behavior are defined in Section 6.4.2 and Section 6.4.3 to support a
wider range of services. wider range of services.
The second part of the masquerading behavior, also called de- The second part of the masquerading behavior, also called de-
masquerading, is an inbound policy attached to the proxy interface masquerading, is an inbound policy attached to the proxy interface
receiving the traffic returning from the service, IFACE-IN. This receiving the traffic returning from the service, IFACE-IN. This
policy inspects the incoming traffic and triggers a regular SRv6 policy inspects the incoming traffic and triggers a regular SRv6
endpoint processing (End) on any IPv6 packet that contains an SRH. endpoint processing (End) on any IPv6 packet that contains an SRH.
This processing occurs before any lookup on the packet Destination This processing occurs before any lookup on the packet Destination
Address is performed and it is sufficient to restore the right active Address is performed and it is sufficient to restore the right active
segment as the Destination Address of the IPv6 packet. SID as the Destination Address of the IPv6 packet.
6.4.1. SRv6 masquerading proxy pseudocode 6.4.1. SRv6 Masquerading Proxy Pseudocode
Masquerading: Upon receiving a packet destined for S, where S is an Masquerading: When processing an IPv6 packet matching a FIB entry
IPv6 masquerading proxy segment, a node N processes it as follows. locally instantiated as an SRv6 masquerading proxy SID, the following
pseudocode is executed.
1. IF NH=SRH & SL > 0 THEN S01. When an SRH is processed {
2. Update the IPv6 DA with SRH[0] S02. If (Segments Left == 0) {
3. Forward the packet on IFACE-OUT S03. Proceed to process the next header in the packet.
4. ELSE S04. }
5. Drop the packet S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S07. }
S08. max_last_entry = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_last_entry) or
(Segments Left > (Last Entry + 1))) {
S10. Send an ICMP Parameter Problem message to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
Interrupt packet processing and discard the packet.
S11. }
S12. Decrement Hop Limit by 1.
S13. Decrement Segments Left by 1.
S14. Copy Segment List[0] from the SRH to the Destination Address
of the IPv6 header.
S15. Submit the packet to the IPv6 module for transmission on
interface IFACE-OUT via NH-ADDR.
S16. }
De-masquerading: Upon receiving a non-link-local IPv6 packet on Figure 23: SID processing for SRv6 masquerading proxy
IFACE-IN, a node N processes it as follows.
1. IF NH=SRH & SL > 0 THEN When processing the Upper-layer header of a packet matching a FIB
2. Decrement SL entry locally instantiated as an SRv6 masquerading proxy SID, process
3. Update the IPv6 DA with SRH[SL] ;; Ref1 the packet as per [I-D.ietf-spring-srv6-network-programming]
4. Lookup DA in appropriate table and proceed accordingly Section 4.1.1.
Ref1: This pseudocode can be augmented to support the Penultimate
Segment Popping (PSP) endpoint flavor. The exact pseudocode
modification are provided in
[I-D.filsfils-spring-srv6-network-programming].
6.4.2. Variant 1: Destination NAT De-masquerading: When processing an IPv6 packet received on the
interface IFACE-IN and with a destination address that does not match
any address of IFACE-IN, the following pseudocode is executed.
S01. When an SRH is processed {
S02. If (IPv6 Hop Limit <= 1) {
S03. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S04. }
S05. If (Segments Left != 0) {
S06. max_last_entry = (Hdr Ext Len / 2) - 1
S07. If ((Last Entry > max_last_entry) or
(Segments Left > Last Entry)) {
S08. Send an ICMP Parameter Problem message to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field,
Interrupt packet processing and discard the packet.
S09. }
S10. Copy Segment List[Segments Left] from the SRH to the
Destination Address of the IPv6 header.
S11. }
S12. Decrement Hop Limit by 1.
S13. Submit the packet to the IPv6 module for transmission to the
next destination.
S14. }
Figure 24: Inbound policy for SRv6 masquerading proxy
6.4.2. Destination NAT Flavor
Services modifying the destination address in the packets they Services modifying the destination address in the packets they
process, such as NATs, can be supported by a masquerading proxy with process, such as NATs, can be supported by reporting the updated
the following modification to the de-masquerading pseudocode. Destination Address back into the Segment List field of the SRH.
De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on The Destination NAT flavor of the SRv6 masquerading proxy is enabled
IFACE-IN, a node N processes it as follows. by adding the following instruction between lines S09 and S10 of the
de-masquerading pseudocode in Figure 24.
1. IF NH=SRH & SL > 0 THEN (... S09. })
2. Update SRH[0] with the IPv6 DA S09.1. Copy the Destination Address of the IPv6 header to the
3. Decrement SL Segment List[0] entry of the SRH.
4. Update the IPv6 DA with SRH[SL] (S10. Copy Segment List[Segments Left] from the SRH to the
5. Lookup DA in appropriate table and proceed accordingly Destination Address of the IPv6 header...)
6.4.3. Variant 2: Caching 6.4.3. Caching Flavor
Services generating packets or acting as endpoints for transport Services generating packets or acting as endpoints for transport
connections can be supported by adding a dynamic caching mechanism connections can be supported by adding a dynamic caching mechanism
similar to the one described in Section 6.2. similar to the one described in Section 6.2.
More details will be added in a future revision of this document. The caching flavor of the SRv6 masquerading proxy is enabled by:
o Adding the following instruction between lines S14 and S15 of the
masquerading pseudocode in Figure 23.
(... S14. Copy Segment List[0] from the SRH to the Destination
Address of the IPv6 header.
S14.1. Copy the IPv6 encapsulation in a CACHE entry associated with
the interface IFACE-IN.
(S15. Submit the packet to the IPv6 module for transmission on
interface IFACE-OUT via NH-ADDR.)
o Updating the de-masquerading pseudocode such that, in addition to
the SRH processing in Figure 24, the following pseudocode is
executed when processing an IPv6 packet (received on the interface
IFACE-IN and with a destination address that does not match any
address of IFACE-IN) that does not contain an SRH.
S01. Retrieve the CACHE entry associated with IFACE-IN.
S02. If the CACHE entry is not empty {
S03. If (IPv6 Hop Limit <= 1) {
S04. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S05. }
S06. Decrement Hop Limit by 1.
S07. Update the IPv6 encapsulation according to the retrieved CACHE
entry.
S08. Submit the packet to the IPv6 module for transmission to the
next destination.
S09. }
7. Metadata 7. Metadata
7.1. MPLS data plane 7.1. MPLS Data Plane
Metadata can be carried for SR-MPLS traffic in a Segment Routing Metadata can be carried for SR-MPLS traffic in a Segment Routing
header inserted between the last MPLS label and the MPLS payload. Header inserted between the last MPLS label and the MPLS payload.
When used solely as a metadata container, the SRH does not carry any When used solely as a metadata container, the SRH does not carry any
segment but only the mandatory header fields, including the tag and segment but only the mandatory header fields, including the tag and
flags, and any TLVs that is required for transporting the metadata. flags, and any TLVs that is required for transporting the metadata.
Since the MPLS encapsulation has no explicit protocol identifier Since the MPLS encapsulation has no explicit protocol identifier
field to indicate the protocol type of the MPLS payload, how to field to indicate the protocol type of the MPLS payload, how to
indicate the presence of metadata in an MPLS packet is a potential indicate the presence of metadata in an MPLS packet is a potential
issue to be addressed. One possible solution is to add the issue to be addressed. One possible solution is to add the
indication about the presence of metadata in the semantic of the indication about the presence of metadata in the semantic of the
SIDs. Note that only the SIDs whose behavior involves looking at the SIDs. Note that only the SIDs whose behavior involves looking at the
metadata or the MPLS payload would need to include such semantic metadata or the MPLS payload would need to include such semantic
(e.g., service segments). Other segments, such as traffic (e.g., service segments). Other segments, such as topological
engineering segments, are not affected by the presence of metadata. segments, are not affected by the presence of metadata. Another,
Another, more generic, solution is to introduce a protocol identifier more generic, solution is to introduce a protocol identifier field
field within the MPLS packet as described in within the MPLS packet as described in
[I-D.xu-mpls-payload-protocol-identifier]. [I-D.xu-mpls-payload-protocol-identifier].
7.2. IPv6 data plane 7.2. IPv6 Data Plane
7.2.1. SRH TLV objects 7.2.1. SRH TLV Objects
The IPv6 SRH TLV objects are designed to carry all sorts of metadata. The IPv6 SRH TLV objects are designed to carry all sorts of metadata.
In particular, the NSH carrier TLV is defined as a container for NSH
metadata.
TLV objects can be imposed by the ingress edge router that steers the TLV objects can be imposed by the ingress edge router that steers the
traffic into the SR service policy. traffic into the SR service policy.
An SR-aware service may impose, modify or remove any TLV object An SR-aware service may impose, modify or remove any TLV object
attached to the first SRH, either by directly modifying the packet attached to the first SRH, either by directly modifying the packet
headers or via a control channel between the service and its headers or via a control channel between the service and its
forwarding plane. forwarding plane.
An SR-aware service that re-classifies the traffic and steers it into An SR-aware service that re-classifies the traffic and steers it into
a new SR service policy (e.g. DPI) may attach any TLV object to the a new SR service policy (e.g. DPI) may attach any TLV object to the
skipping to change at page 25, line 36 skipping to change at page 31, line 34
o Type: to be assigned by IANA. o Type: to be assigned by IANA.
o Length: the total length of the TLV. o Length: the total length of the TLV.
o Flags: 8 bits. No flags are defined in this document. SHOULD be o Flags: 8 bits. No flags are defined in this document. SHOULD be
set to 0 on transmission and MUST be ignored on receipt. set to 0 on transmission and MUST be ignored on receipt.
o Service Metadata: a list of Service Metadata TLV as defined in o Service Metadata: a list of Service Metadata TLV as defined in
[RFC8300] for NSH MD Type 2. [RFC8300] for NSH MD Type 2.
7.2.2. SRH tag 7.2.2. SRH Tag
The SRH tag identifies a packet as part of a group or class of The SRH tag identifies a packet as part of a group or class of
packets [I-D.ietf-6man-segment-routing-header]. packets [I-D.ietf-6man-segment-routing-header].
In the context of service programming, this field can be used to In the context of service programming, this field can be used to
encode basic metadata in the SRH. An example use case would be to encode basic metadata in the SRH. An example use-case is to leverage
leverage the SRH tag to encode a policy ID which could be leveraged the SRH tag to encode a policy ID. This policy ID can then be used
in an SR-aware function to determine which processing policy to apply by an SR-aware function to identify a particular processing policy to
rather than having doing local classification or leverage alternate be applied on that packet.
encapsulations.
8. Implementation status 8. Implementation Status
This section is to be removed prior to publishing as an RFC. This section is to be removed prior to publishing as an RFC.
8.1. SR-aware services 8.1. SR-Aware Services
Specific SRv6 support has been implemented for the below open-source Specific SRv6 support has been implemented for the below open-source
services: services:
o Iptables (1.6.2 and later) [IPTABLES] o Iptables (1.6.2 and later) [IPTABLES]
o Nftables (0.8.4 and later) [NFTABLES] o Nftables (0.8.4 and later) [NFTABLES]
o Snort [SNORT] o Snort [SNORT]
In addition, any service relying on the Linux kernel, version 4.10 In addition, any service relying on the Linux kernel, version 4.10
and later, or FD.io VPP for packet forwarding can be considered as and later, or FD.io VPP for packet forwarding can be considered as
SR-aware. SR-aware.
8.2. Proxy behaviors 8.2. Proxy Behaviors
The static SR proxy is available for SR-MPLS and SRv6 on various The static SR proxy is available for SR-MPLS and SRv6 on various
Cisco hardware and software platforms. Furthermore, the following Cisco hardware and software platforms. Furthermore, the following
proxies are available on open-source software. proxies are available on open-source software.
+-------------+-------------+ +-------------+-------------+
| VPP | Linux | | VPP | Linux |
+---+-----------------------------------+-------------+-------------+ +---+-----------------------------------+-------------+-------------+
| M | Static proxy | Available | In progress | | M | Static proxy | Available | In progress |
| P | | | | | P | | | |
skipping to change at page 26, line 44 skipping to change at page 32, line 44
+---+-----------------------------------+-------------+-------------+ +---+-----------------------------------+-------------+-------------+
| | Static proxy | Available | In progress | | | Static proxy | Available | In progress |
| S | | | | | S | | | |
| R | Dynamic proxy | Available | Available | | R | Dynamic proxy | Available | Available |
| v | | | | | v | | | |
| 6 | Shared memory proxy | In progress | In progress | | 6 | Shared memory proxy | In progress | In progress |
| | | | | | | | | |
| | Masquerading proxy | Available | Available | | | Masquerading proxy | Available | Available |
+---+-----------------------------------+-------------+-------------+ +---+-----------------------------------+-------------+-------------+
Figure 6: Open-source implementation status table Figure 25: Open-source implementation status table
9. Related works 9. Related Works
The Segment Routing solution addresses a wide problem that covers The Segment Routing solution addresses a wide problem that covers
both topological and service policies. The topological and service both topological and service policies. The topological and service
instructions can be either deployed in isolation or in combination. instructions can be either deployed in isolation or in combination.
SR has thus a wider applicability than the architecture defined in SR has thus a wider applicability than the architecture defined in
[RFC7665]. Furthermore, the inherent property of SR is a stateless [RFC7665]. Furthermore, the inherent property of SR is a stateless
network fabric. In SR, there is no state within the fabric to network fabric. In SR, there is no state within the fabric to
recognize a flow and associate it with a policy. State is only recognize a flow and associate it with a policy. State is only
present at the ingress edge of the SR domain, where the policy is present at the ingress edge of the SR domain, where the policy is
encoded into the packets. This is completely different from other encoded into the packets. This is completely different from other
skipping to change at page 27, line 23 skipping to change at page 33, line 23
10.1. SRv6 Endpoint Behaviors 10.1. SRv6 Endpoint Behaviors
This I-D requests the IANA to allocate, within the "SRv6 Endpoint This I-D requests the IANA to allocate, within the "SRv6 Endpoint
Behaviors" sub-registry belonging to the top-level "Segment-routing Behaviors" sub-registry belonging to the top-level "Segment-routing
with IPv6 dataplane (SRv6) Parameters" registry, the following with IPv6 dataplane (SRv6) Parameters" registry, the following
allocations: allocations:
Value Description Reference Value Description Reference
-------------------------------------------------------------- --------------------------------------------------------------
TBA1 End.AN - SR-aware function (native) [This.ID] TBA1-1 End.AN - SR-aware function (native) [This.ID]
TBA2 End.AS - Static proxy [This.ID] TBA1-2 End.AS - Static proxy [This.ID]
TBA3 End.AD - Dynamic proxy [This.ID] TBA1-3 End.AD - Dynamic proxy [This.ID]
TBA4 End.AM - Masquerading proxy [This.ID] TBA1-4 End.AM - Masquerading proxy [This.ID]
TBA1-5 End.AM - Masquerading proxy with NAT [This.ID]
TBA1-6 End.AM - Masquerading proxy with Caching [This.ID]
TBA1-7 End.AM - Masquerading proxy with NAT & [This.ID]
Caching
10.2. Segment Routing Header TLVs 10.2. Segment Routing Header TLVs
This I-D requests the IANA to allocate, within the "Segment Routing This I-D requests the IANA to allocate, within the "Segment Routing
Header TLVs" registry, the following allocations: Header TLVs" registry, the following allocations:
Value Description Reference Value Description Reference
---------------------------------------------- ----------------------------------------------
TBA1 Opaque Metadata TLV [This.ID] TBA2-1 Opaque Metadata TLV [This.ID]
TBA2 NSH Carrier TLV [This.ID] TBA2-2 NSH Carrier TLV [This.ID]
11. Security Considerations 11. Security Considerations
The security requirements and mechanisms described in [RFC8402], The security requirements and mechanisms described in [RFC8402],
[I-D.ietf-6man-segment-routing-header] and [I-D.ietf-6man-segment-routing-header] and
[I-D.filsfils-spring-srv6-network-programming] also apply to this [I-D.ietf-spring-srv6-network-programming] also apply to this
document. document.
This document does not introduce any new security vulnerabilities. This document does not introduce any new security vulnerabilities.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Thierry Couture, Ketan Talaulikar, The authors would like to thank Thierry Couture, Ketan Talaulikar,
Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein
and Joel M. Halpern for their valuable comments and suggestions on and Joel M. Halpern for their valuable comments and suggestions on
the document. the document.
skipping to change at page 29, line 40 skipping to change at page 36, line 5
Jisu Bhattacharya Jisu Bhattacharya
Cisco Systems, Inc. Cisco Systems, Inc.
United States of America United States of America
Email: jisu@cisco.com Email: jisu@cisco.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
Routing Header (SRH)", draft-ietf-6man-segment-routing- (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
header-26 (work in progress), October 2019. progress), October 2019.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019. (work in progress), May 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
bogdanov@google.com, b., and P. Mattes, "Segment Routing P. Mattes, "Segment Routing Policy Architecture", draft-
Policy Architecture", draft-ietf-spring-segment-routing- ietf-spring-segment-routing-policy-06 (work in progress),
policy-03 (work in progress), May 2019. December 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-10 (work in
progress), February 2020.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
14.2. Informative References 14.2. Informative References
[I-D.dawra-idr-bgp-sr-service-chaining] [I-D.dawra-idr-bgp-sr-service-chaining]
Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d.,
Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F.,
and K. Talaulikar, "BGP Control Plane Extensions for and K. Talaulikar, "BGP Control Plane Extensions for
Segment Routing based Service Chaining", draft-dawra-idr- Segment Routing based Service Chaining", draft-dawra-idr-
bgp-sr-service-chaining-02 (work in progress), January bgp-sr-service-chaining-02 (work in progress), January
2018. 2018.
 End of changes. 122 change blocks. 
327 lines changed or deleted 586 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/