On Mon, 2022-09-12 at 19:16 +0200, Andrea Mayer wrote: > The NEXT-C-SID mechanism described in [1] offers the possibility of > encoding several SRv6 segments within a single 128 bit SID address. Such > a SID address is called a Compressed SID (C-SID) container. In this way, > the length of the SID List can be drastically reduced. > > A SID instantiated with the NEXT-C-SID flavor considers an IPv6 address > logically structured in three main blocks: i) Locator-Block; ii) > Locator-Node Function; iii) Argument. > > C-SID container > +------------------------------------------------------------------+ > > Locator-Block |Loc-Node| Argument | > > |Function| | > +------------------------------------------------------------------+ > <--------- B -----------> <- NF -> <------------- A ---------------> > > (i) The Locator-Block can be any IPv6 prefix available to the provider; > > (ii) The Locator-Node Function represents the node and the function to > be triggered when a packet is received on the node; > > (iii) The Argument carries the remaining C-SIDs in the current C-SID > container. > > The NEXT-C-SID mechanism relies on the "flavors" framework defined in > [2]. The flavors represent additional operations that can modify or > extend a subset of the existing behaviors. > > This patch introduces the support for flavors in SRv6 End behavior > implementing the NEXT-C-SID one. An SRv6 End behavior with NEXT-C-SID > flavor works as an End behavior but it is capable of processing the > compressed SID List encoded in C-SID containers. > > An SRv6 End behavior with NEXT-C-SID flavor can be configured to support > user-provided Locator-Block and Locator-Node Function lengths. In this > implementation, such lengths must be evenly divisible by 8 (i.e. must be > byte-aligned), otherwise the kernel informs the user about invalid > values with a meaningful error code and message through netlink_ext_ack. > > If Locator-Block and/or Locator-Node Function lengths are not provided > by the user during configuration of an SRv6 End behavior instance with > NEXT-C-SID flavor, the kernel will choose their default values i.e., > 32-bit Locator-Block and 16-bit Locator-Node Function. > > [1] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression > [2] - https://datatracker.ietf.org/doc/html/rfc8986 > > Signed-off-by: Andrea Mayer <andrea.mayer@xxxxxxxxxxx> > --- > include/uapi/linux/seg6_local.h | 24 +++ > net/ipv6/seg6_local.c | 335 +++++++++++++++++++++++++++++++- > 2 files changed, 356 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h > index 332b18f318f8..4fdc424c9cb3 100644 > --- a/include/uapi/linux/seg6_local.h > +++ b/include/uapi/linux/seg6_local.h > @@ -28,6 +28,7 @@ enum { > SEG6_LOCAL_BPF, > SEG6_LOCAL_VRFTABLE, > SEG6_LOCAL_COUNTERS, > + SEG6_LOCAL_FLAVORS, > __SEG6_LOCAL_MAX, > }; > #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1) > @@ -110,4 +111,27 @@ enum { > > #define SEG6_LOCAL_CNT_MAX (__SEG6_LOCAL_CNT_MAX - 1) > > +/* SRv6 End* Flavor attributes */ > +enum { > + SEG6_LOCAL_FLV_UNSPEC, > + SEG6_LOCAL_FLV_OPERATION, > + SEG6_LOCAL_FLV_LCBLOCK_BITS, > + SEG6_LOCAL_FLV_LCNODE_FN_BITS, > + __SEG6_LOCAL_FLV_MAX, > +}; > + > +#define SEG6_LOCAL_FLV_MAX (__SEG6_LOCAL_FLV_MAX - 1) > + > +/* Designed flavor operations for SRv6 End* Behavior */ > +enum { > + SEG6_LOCAL_FLV_OP_UNSPEC, > + SEG6_LOCAL_FLV_OP_PSP, > + SEG6_LOCAL_FLV_OP_USP, > + SEG6_LOCAL_FLV_OP_USD, > + SEG6_LOCAL_FLV_OP_NEXT_CSID, > + __SEG6_LOCAL_FLV_OP_MAX > +}; > + > +#define SEG6_LOCAL_FLV_OP_MAX (__SEG6_LOCAL_FLV_OP_MAX - 1) > + > #endif > diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c > index f43e6f0baac1..8370726ae7bf 100644 > --- a/net/ipv6/seg6_local.c > +++ b/net/ipv6/seg6_local.c > @@ -73,6 +73,55 @@ struct bpf_lwt_prog { > char *name; > }; > > +/* default length values (expressed in bits) for both Locator-Block and > + * Locator-Node Function. > + * > + * Both SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS *must* be: > + * i) greater than 0; > + * ii) evenly divisible by 8. In other terms, the lengths of the > + * Locator-Block and Locator-Node Function must be byte-aligned (we can > + * relax this constraint in the future if really needed). > + * > + * Moreover, a third condition must hold: > + * iii) SEG6_LOCAL_LCBLOCK_DBITS + SEG6_LOCAL_LCNODE_FN_DBITS <= 128. > + * > + * The correctness of SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS > + * values are checked during the kernel compilation. If the compilation stops, > + * check the value of these parameters to see if they meet conditions (i), (ii) > + * and (iii). > + */ > +#define SEG6_LOCAL_LCBLOCK_DBITS 32 > +#define SEG6_LOCAL_LCNODE_FN_DBITS 16 > + > +/* The following next_csid_chk_{cntr,lcblock,lcblock_fn}_bits macros can be > + * used directly to check whether the lengths (in bits) of Locator-Block and > + * Locator-Node Function are valid according to (i), (ii), (iii). > + */ > +#define next_csid_chk_cntr_bits(blen, flen) \ > + ((blen) + (flen) > 128) > + > +#define next_csid_chk_lcblock_bits(blen) \ > +({ \ > + typeof(blen) __tmp = blen; \ > + (!__tmp || __tmp > 120 || (__tmp & 0x07)); \ Just a note to mention that in theory a caller could pass a signed argument, so the above check does not ensure that __tmp is acutally >= 8. All the current callers use unsigned arguements, so it still looks safe. Cheers, Paolo
