1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
.. _srv6_as_plugin_doc:
SRv6 static proxy
=================
The document describes SRv6 endpoint to SR-unaware appliance via static
proxy (End.AS)
Overview
--------
The static proxy is an SR endpoint behavior for processing SR-MPLS or
SRv6 encapsulated traffic on behalf of an SR-unaware SF. This 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, IPv4 or IPv6.
A static SR proxy segment is associated with the following mandatory
parameters:
- INNER-TYPE: Inner packet type
- S-ADDR: Ethernet or IP address of the SF (only for inner type IPv4
and IPv6)
- IFACE-OUT: Local interface for sending traffic towards the SF
- IFACE-IN: Local interface receiving the traffic coming back from the
SF
- CACHE: SR information to be attached on the traffic coming back from
the SF, including at least
- CACHE.SA: IPv6 source address (SRv6 only)
- CACHE.LIST: Segment list expressed as MPLS labels or IPv6 address
A static SR proxy segment is thus defined for a specific SF, inner
packet type and cached SR information. It is also bound to a pair of
directed interfaces on the proxy. These may be both directions of a
single interface, or opposite directions of two different interfaces.
The latter is recommended in case the SF is to be used as part of a
bi-directional SR SC policy. If the proxy and the SF both support
802.1Q, IFACE-OUT and IFACE-IN can also represent sub-interfaces.
The first part of this behavior is triggered when the proxy node
receives a packet whose active segment matches a segment associated with
the static proxy behavior. It removes the SR information from the packet
then sends it on a specific interface towards the associated SF. This SR
information corresponds to the full label stack for SR-MPLS or to the
encapsulation IPv6 header with any attached extension header in the case
of SRv6.
The second part is an inbound policy attached to the proxy interface
receiving the traffic returning from the SF, IFACE-IN. This policy
attaches to the incoming traffic the cached SR information associated
with the SR proxy segment. If the proxy segment uses the SR-MPLS data
plane, CACHE contains a stack of labels to be pushed on top the packets.
With the SRv6 data plane, CACHE is defined as a source address, an
active segment and an optional SRH (tag, segments left, segment list and
metadata). The proxy encapsulates the packets with an IPv6 header that
has the source address, the active segment as destination address and
the SRH as a routing extension header. After the SR information has been
attached, the packets are forwarded according to the active segment,
which is represented by the top MPLS label or the IPv6 Destination
Address.
In this scenario, there are no restrictions on the operations that can
be performed by the SF on the stream of packets. It may operate at all
protocol layers, terminate transport layer connections, generate new
packets and initiate transport layer connections. This behavior may also
be used to integrate an IPv4-only SF into an SRv6 policy. However, a
static SR proxy segment can be used in only one service chain at a time.
As opposed to most other segment types, a static SR proxy segment is
bound to a unique list of segments, which represents a directed SR SC
policy. This is due to the cached SR information being defined in the
segment configuration. This limitation only prevents multiple segment
lists from using the same static SR proxy segment at the same time, but
a single segment list can be shared by any number of traffic flows.
Besides, since the returning traffic from the SF is re-classified based
on the incoming interface, an interface can be used as receiving
interface (IFACE-IN) only for a single SR proxy segment at a time. In
the case of a bi-directional SR SC policy, a different SR proxy segment
and receiving interface are required for the return direction.
For more information, please see
`draft-xuclad-spring-sr-service-chaining <https://datatracker.ietf.org/doc/draft-xuclad-spring-sr-service-chaining/>`__.
CLI configuration
-----------------
The following command instantiates a new End.AS segment that sends the
inner packets on interface ``IFACE-OUT`` towards an appliance at address
``S-ADDR`` and restores the segment list ``<S1, S2, S3>`` with a source
address ``SRC-ADDR`` on the packets coming back on interface
``IFACE-IN``.
::
sr localsid address SID behavior end.as nh S-ADDR oif IFACE-OUT iif IFACE-IN src SRC-ADDR next S1 next S2 next S3
For example, the below command configures the SID ``1::A1`` with an
End.AS function for sending traffic on interface
``GigabitEthernet0/8/0`` to the appliance at address ``A1::``, and
receiving it back on interface ``GigabitEthernet0/9/0``.
::
sr localsid address 1::A1 behavior end.as nh A1:: oif GigabitEthernet0/8/0 iif GigabitEthernet0/9/0 src 1:: next 2::20 next 3::30 next 4::40
Pseudocode
----------
Static proxy for inner type IPv4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upon receiving an IPv6 packet destined for S, where S is an IPv6 static
proxy segment for IPv4 traffic, a node N does:
::
IF ENH == 4 THEN ;; Ref1
Remove the (outer) IPv6 header and its extension headers
Forward the exposed packet on IFACE-OUT towards S-ADDR
ELSE
Drop the packet
**Ref1:** 4 refers to IPv4 encapsulation as defined by IANA allocation
for Internet Protocol Numbers.
Upon receiving a non link-local IPv4 packet on IFACE-IN, a node N does:
::
Decrement TTL and update checksum
IF CACHE.SRH THEN ;; Ref2
Push CACHE.SRH on top of the existing IPv4 header
Set NH value of the pushed SRH to 4
Push outer IPv6 header with SA, DA and traffic class from CACHE
Set outer payload length and flow label
Set NH value to 43 if an SRH was added, or 4 otherwise
Lookup outer DA in appropriate table and proceed accordingly
**Ref2:** CACHE.SRH represents the SRH defined in CACHE, if any, for the
static SR proxy segment associated with IFACE-IN.
Static proxy for inner type IPv6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upon receiving an IPv6 packet destined for S, where S is an IPv6 static
proxy segment for IPv6 traffic, a node N does:
::
IF ENH == 41 THEN ;; Ref1
Remove the (outer) IPv6 header and its extension headers
Forward the exposed packet on IFACE-OUT towards S-ADDR
ELSE
Drop the packet
**Ref1:** 41 refers to IPv6 encapsulation as defined by IANA allocation
for Internet Protocol Numbers.
Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N does:
::
Decrement Hop Limit
IF CACHE.SRH THEN ;; Ref2
Push CACHE.SRH on top of the existing IPv6 header
Set NH value of the pushed SRH to 41
Push outer IPv6 header with SA, DA and traffic class from CACHE
Set outer payload length and flow label
Set NH value to 43 if an SRH was added, or 41 otherwise
Lookup outer DA in appropriate table and proceed accordingly
**Ref2:** CACHE.SRH represents the SRH defined in CACHE, if any, for the
static SR proxy segment associated with IFACE-IN.
|
