doc/OSPF-SR.rst

   1 OSPF Segment Routing
   2 ====================
   3
   4 This is an EXPERIMENTAL support of draft
   5 `draft-ietf-ospf-segment-routing-extensions-24`.
   6 DON'T use it for production network.
   7
   8 Implementation details
   9 ----------------------
  10
  11 Concepts
  12 ~~~~~~~~
  13
  14 Segment Routing used 3 differents OPAQUE LSA in OSPF to carry the various
  15 information:
  16
  17 * **Router Information:** flood the Segment Routing capabilities of the node.
  18   This include the supported algorithms, the Segment Routing Global Block
  19   (SRGB) and the Maximum Stack Depth (MSD).
  20 * **Extended Link:** flood the Adjaceny and Lan Adjacency Segment Identifier
  21 * **Extended Prefix:** flood the Prefix Segment Identifier
  22
  23 The implementation follow previous TE and Router Information codes. It used the
  24 OPAQUE LSA functions defined in ospf_opaque.[c,h] as well as the OSPF API. This
  25 latter is mandatory for the implementation as it provides the Callback to
  26 Segment Routing functions (see below) when an Extended Link / Prefix or Router
  27 Information LSA s are received.
  28
  29 Overview
  30 ~~~~~~~~
  31
  32 Following files where modified or added:
  33
  34 * ospd_ri.[c,h] have been modified to add the new TLVs for Segment Routing.
  35 * ospf_ext.[c,h] implement RFC7684 as base support of Extended Link and Prefix
  36   Opaque LSA.
  37 * ospf_sr.[c,h] implement the earth of Segment Routing. It adds a new Segment
  38   Routing database to manage Segment Identifiers per Link and Prefix and
  39   Segment Routing enable node, Callback functions to process incoming LSA and
  40   install MPLS FIB entry through Zebra.
  41
  42 The figure below shows the relation between the various files:
  43
  44 * ospf_sr.c centralized all the Segment Routing processing. It receives Opaque
  45   LSA Router Information (4.0.0.0) from ospf_ri.c and Extended Prefix
  46   (7.0.0.X) Link (8.0.0.X) from ospf_ext.c. Once received, it parse TLVs and
  47   SubTLVs and store information in SRDB (which is defined in ospf_sr.h). For
  48   each received LSA, NHLFE is computed and send to Zebra to add/remove new
  49   MPLS labels entries and FEC. New CLI configurations are also centralized in
  50   ospf_sr.c. This CLI will trigger the flooding of new LSA Router Information
  51   (4.0.0.0), Extended Prefix (7.0.0.X) and Link (8.0.0.X) by ospf_ri.c,
  52   respectively ospf_ext.c.
  53 * ospf_ri.c send back to ospf_sr.c received Router Information LSA and update
  54   Self Router Information LSA with paramters provided by ospf_sr.c i.e. SRGB
  55   and MSD. It use ospf_opaque.c functions to send/received these Opaque LSAs.
  56 * ospf_ext.c send back to ospf_sr.c received Extended Prefix and Link Opaque
  57   LSA and send self Extended Prefix and Link Opaque LSA through ospf_opaque.c
  58   functions.
  59
  60 ::
  61
  62                     +-----------+     +-------+
  63                     |           |     |       |
  64                     | ospf_sr.c +-----+  SRDB |
  65         +-----------+           +--+  |       |
  66         |           +-^-------^-+  |  +-------+
  67         |             |   |   |    |
  68         |             |   |   |    |
  69         |             |   |   |    +--------+
  70         |             |   |   |             |
  71     +---v----------+  |   |   |       +-----v-------+
  72     |              |  |   |   |       |             |
  73     | ospf_ri.c    +--+   |   +-------+ ospf_ext.c  |
  74     | LSA 4.0.0.0  |      |           | LSA 7.0.0.X |
  75     |              |      |           | LSA 8.0.0.X |
  76     +---^----------+      |           |             |
  77         |                 |           +-----^-------+
  78         |                 |                 |
  79         |                 |                 |
  80         |        +--------v------------+    |
  81         |        |                     |    |
  82         |        | ZEBRA: Labels + FEC |    |
  83         |        |                     |    |
  84         |        +---------------------+    |
  85         |                                   |
  86         |                                   |
  87         |         +---------------+         |
  88         |         |               |         |
  89         +---------> ospf_opaque.c <---------+
  90                   |               |
  91                   +---------------+
  92
  93       Figure 1: Overview of Segment Routing interaction
  94
  95 Module interactions
  96 ~~~~~~~~~~~~~~~~~~~
  97
  98 To process incoming LSA, the code is based on the capability to call `hook()`
  99 functions when LSA are inserted or delete to / from the LSDB and the
 100 possibility to register particular treatment for Opaque LSA. The first point
 101 is provided by the OSPF API feature and the second by the Opaque implementation
 102 itself. Indeed, it is possible to register callback function for a given Opaque
 103 LSA ID (see `ospf_register_opaque_functab()` function defined in
 104 `ospf_opaque.c`). Each time a new LSA is added to the LSDB, the
 105 `new_lsa_hook()` function previously register for this LSA type is called. For
 106 Opaque LSA it is the `ospf_opaque_lsa_install_hook()`.  For deletion, it is
 107 `ospf_opaque_lsa_delete_hook()`.
 108
 109 Note that incoming LSA which is already present in the LSDB will be inserted
 110 after the old instance of this LSA remove from the LSDB. Thus, after the first
 111 time, each incoming LSA will trigger a `delete` following by an `install`. This
 112 is not very helpfull to handle real LSA deletion. In fact, LSA deletion is done
 113 by Flushing LSA i.e. flood LSA after seting its age to MAX_AGE. Then, a garbage
 114 function has the role to remove all LSA with `age == MAX_AGE` in the LSDB. So,
 115 to handle LSA Flush, the best is to look to the LSA age to determine if it is
 116 an installation or a future deletion i.e. the flushed LSA is first store in the
 117 LSDB with MAX_AGE waiting for the garbage collector function.
 118
 119 Router Information LSAs
 120 ^^^^^^^^^^^^^^^^^^^^^^^
 121
 122 To activate Segment Routing, new CLI command `segment-routing on` has been
 123 introduced. When this command is activated, function
 124 `ospf_router_info_update_sr()` is called to indicate to Router Information
 125 process that Segment Routing TLVs must be flood. Same function is called to
 126 modify the Segment Routing Global Block (SRGB) and Maximum Stack Depth (MSD)
 127 TLV. Only Shortest Path First (SPF) Algorithm is supported, so no possiblity
 128 to modify this TLV is offer by the code.
 129
 130 When Opaque LSA Tyep 4 i.e. Router Information are stored in LSDB, function
 131 `ospf_opaque_lsa_install_hook()` will call the previously registered function
 132 `ospf_router_info_lsa_update()`. In turn, the function will simply trigger
 133 `ospf_sr_ri_lsa_update()` or `ospf_sr_ri_lsa_delete` in function of the LSA
 134 age. Before, it verifies that the LSA Opaque Type is 4 (Router Information).
 135 Self Opaque LSA are not send back to the Segment Routing functions as
 136 information are already stored.
 137
 138 Extended Link Prefix LSAs
 139 ^^^^^^^^^^^^^^^^^^^^^^^^^
 140
 141 Like for Router Information, Segment Routing is activate at the Extended
 142 Link/Prefix level with new `segment-routing on` command. This trigger
 143 automtically the flooding of Extended Link LSA for all ospf interface where
 144 adjacency is full. For Extended Prefix LSA, the new CLI command
 145 `segment-routing prefix ...` will trigger the flooding of Prefix SID
 146 TLV/SubTLVs.
 147
 148 When Opaque LSA Type 7 i.e. Extended Prefix and Type 8 i.e. Extended Link are
 149 store in the LSDB, `ospf_ext_pref_update_lsa()` respectively
 150 `ospf_ext_link_update_lsa()` are called like for Router Information LSA. In
 151 turn, they respectively trigger `ospf_sr_ext_prefix_lsa_update()` /
 152 `ospf_sr_ext_link_lsa_update()` or `ospf_sr_ext_prefix_lsa_delete()` /
 153 `ospf_sr_ext_link_lsa_delete()` if the LSA age is equal to MAX_AGE.
 154
 155 Zebra
 156 ^^^^^
 157
 158 When a new MPLS entry or new Forwarding Equivalent Class (FEC) must be added or
 159 deleted in the data plane, `add_sid_nhlfe()` respectively `del_sid_nhlfe()` are
 160 called. Once check the validity of labels, they are send to ZEBRA layer through
 161 `ZEBRA_MPLS_LABELS_ADD` command, respectively `ZEBRA_MPLS_LABELS_DELETE`
 162 command for deletion. This is completed by a new labelled route through
 163 `ZEBRA_ROUTE_ADD` command, respectively `ZEBRA_ROUTE_DELETE` command.
 164
 165 Configuration
 166 -------------
 167
 168 Linux Kernel
 169 ~~~~~~~~~~~~
 170
 171 In order to use OSPF Segment Routing, you must setup MPLS data plane. Up to
 172 know, only Linux Kernel version >= 4.5 is supported.
 173
 174 First, the MPLS modules aren't loaded by default, so you'll need to load them
 175 yourself:
 176
 177 ::
 178
 179         modprobe mpls_router
 180         modprobe mpls_gso
 181         modprobe mpls_iptunnel
 182
 183 Then, you must activate MPLS on the interface you would used:
 184
 185 ::
 186
 187         sysctl -w net.mpls.conf.enp0s9.input=1
 188         sysctl -w net.mpls.conf.lo.input=1
 189         sysctl -w net.mpls.platform_labels=1048575
 190
 191 The last line fix the maximum MPLS label value.
 192
 193 Once OSPFd start with Segment Routing, you could check that MPLS routes are
 194 enable with:
 195
 196 ::
 197
 198         ip -M route
 199         ip route
 200
 201 The first command show the MPLS LFIB table while the second show the FIB
 202 table which contains route with MPLS label encapsulation.
 203
 204 If you disable Penultimate Hop Popping with the `no-php-flag` (see below), you
 205 MUST check that RP filter is not enable for the interface you intend to use,
 206 especially the `lo` one. For that purpose, disable RP filtering with:
 207
 208 ::
 209
 210         systcl -w net.ipv4.conf.all.rp_filter=0
 211         sysctl -w net.ipv4.conf.lo.rp_filter=0
 212
 213 OSPFd
 214 ~~~~~
 215
 216 Here it is a simple example of configuration to enable Segment Routing. Note
 217 that `opaque capability` and `router information` must be set to activate
 218 Opaque LSA prior to Segment
 219 Routing.
 220
 221 ::
 222
 223         router ospf
 224          ospf router-id 192.168.1.11
 225          capability opaque
 226           mpls-te on
 227           mpls-te router-address 192.168.1.11
 228          router-info area 0.0.0.0
 229          segment-routing on
 230          segment-routing global-block 10000 19999
 231          segment-routing node-msd 8
 232          segment-routing prefix 192.168.1.11/32 index 1100
 233
 234 The first segment-routing statement enable it. The Second one set the SRGB,
 235 third line the MSD and finally, set the Prefix SID index for a given prefix.
 236 Note that only prefix of Loopback interface could be configured with a Prefix
 237 SID. It is possible to add `no-php-flag` at the end of the prefix command to
 238 disbale Penultimate Hop Popping. This advertises peers that they MUST NOT pop
 239 the MPLS label prior to sending the packet.
 240
 241 Known limitations
 242 -----------------
 243
 244 * Runs only within default VRF
 245 * Only single Area is supported. ABR is not yet supported
 246 * Only SPF algorithm is supported
 247 * Extended Prefix Range is not supported
 248 * MPLS table are not flush at startup. Thus, restarting zebra process is
 249   mandatory to remove old MPLS entries in the data plane after a crash of
 250   ospfd daemon
 251 * Due to a bug in OSPF Opaque, LSA are not flood when enable Segment Routing
 252   through CLI once OSPFd started. You must configure Segment Routing within
 253   configuration file before launching OSPFd
 254 * With NO Penultimate Hop Popping, it is not possible to express a Segment
 255   Path with an Adjacency SID due to the impossibility for the Linux Kernel to
 256   perform double POP instruction.
 257
 258 Credits
 259 -------
 260
 261 * Author: Anselme Sawadogo <anselmesawadogo@gmail.com>
 262 * Author: Olivier Dugeon <olivier.dugeon@orange.com>
 263 * Copyright (C) 2016 - 2018 Orange Labs http://www.orange.com
 264
 265 This work has been performed in the framework of the H2020-ICT-2014
 266 project 5GEx (Grant Agreement no. 671636), which is partially funded
 267 by the European Commission.
 268
 269