[net-next v2 0/3] 802.21 and MPLS headers and classification

[net-next v2 0/3] 802.21 and MPLS headers and classification

[Simon Wunderlich]

Hi,

this series contains a header file proposal for MPLS labels. These
labels do not seem to be properly defined in the kernel so far. We are
developing a wired/wireless 802.21/MPLS switch and need to check the
MPLS labels to use the traffic control info for transmissions over
802.11 networks.

Thanks to Joe Perches for comments - changes have been made according
to his suggestions, check the individual patches for details.

Thanks,
     Simon

Simon Wunderlich (3):
  if_ether.h: add IEEE 802.21 Ethertype
  UAPI: add MPLS label stack definition
  cfg80211: add MPLS and 802.21 classification

 include/linux/mpls.h          |    6 ++++++
 include/uapi/linux/if_ether.h |    1 +
 include/uapi/linux/mpls.h     |   34 ++++++++++++++++++++++++++++++++++
 net/wireless/util.c           |   24 ++++++++++++++++++++++++
 4 files changed, 65 insertions(+)
 create mode 100644 include/linux/mpls.h
 create mode 100644 include/uapi/linux/mpls.h

-- 
1.7.10.4

[net-next v2 1/3] if_ether.h: add IEEE 802.21 Ethertype

[Simon Wunderlich]

Add the Ethertype for IEEE Std 802.21 - Media Independent Handover
Protocol. This Ethertype is used for network control messages.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
 include/uapi/linux/if_ether.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 2ce0f6a..2e27208 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -89,6 +89,7 @@
 #define ETH_P_FCOE	0x8906		/* Fibre Channel over Ethernet  */
 #define ETH_P_TDLS	0x890D          /* TDLS */
 #define ETH_P_FIP	0x8914		/* FCoE Initialization Protocol */
+#define ETH_P_80221	0x8917		/* IEEE 802.21 Media Independent Handover Protocol */
 #define ETH_P_QINQ1	0x9100		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
 #define ETH_P_QINQ2	0x9200		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
 #define ETH_P_QINQ3	0x9300		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
-- 
1.7.10.4

[net-next v2 2/3] UAPI: add MPLS label stack definition

[Simon Wunderlich]

Labels for the Multiprotocol Label Switching are defined in RFC 3032
which was superseded by RFC 5462. Add the definition to UAPI and a stub
header for include/linux.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
Changes to first version:

 * add stub mpls header in include/linux/mpls.h for users inside the
   kernel
---
 include/linux/mpls.h      |    6 ++++++
 include/uapi/linux/mpls.h |   34 ++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+)
 create mode 100644 include/linux/mpls.h
 create mode 100644 include/uapi/linux/mpls.h

diff --git a/include/linux/mpls.h b/include/linux/mpls.h
new file mode 100644
index 0000000..9999145
--- /dev/null
+++ b/include/linux/mpls.h
@@ -0,0 +1,6 @@
+#ifndef _LINUX_MPLS_H
+#define _LINUX_MPLS_H
+
+#include <uapi/linux/mpls.h>
+
+#endif  /* _LINUX_MPLS_H */
diff --git a/include/uapi/linux/mpls.h b/include/uapi/linux/mpls.h
new file mode 100644
index 0000000..15c8260
--- /dev/null
+++ b/include/uapi/linux/mpls.h
@@ -0,0 +1,34 @@
+#ifndef _UAPI_MPLS_H
+#define _UAPI_MPLS_H
+
+#include <linux/types.h>
+#include <asm/byteorder.h>
+
+/* Reference: RFC 5462, RFC 3032
+ *
+ *  0                   1                   2                   3
+ *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |                Label                  | TC  |S|       TTL     |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ *	Label:  Label Value, 20 bits
+ *	TC:     Traffic Class field, 3 bits
+ *	S:      Bottom of Stack, 1 bit
+ *	TTL:    Time to Live, 8 bits
+ */
+
+struct mpls_label_stack {
+	__be32 entry;
+};
+
+#define MPLS_LS_LABEL_MASK      0xFFFFF000
+#define MPLS_LS_LABEL_SHIFT     12
+#define MPLS_LS_TC_MASK         0x00000E00
+#define MPLS_LS_TC_SHIFT        9
+#define MPLS_LS_S_MASK          0x00000100
+#define MPLS_LS_S_SHIFT         8
+#define MPLS_LS_TTL_MASK        0x000000FF
+#define MPLS_LS_TTL_SHIFT       0
+
+#endif /* _UAPI_MPLS_H */
-- 
1.7.10.4

[net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Simon Wunderlich]

MPLS labels may contain traffic control information, which should be
evaluated and used by the wireless subsystem if present.

Also check for IEEE 802.21 which is always network control traffic.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
Changes to first version:

 * include linux/mpls.h, not the UAPI one
 * change __constant_htons to htons
---
 net/wireless/util.c |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index d39c371..54956eb 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -11,6 +11,7 @@
 #include <net/ip.h>
 #include <net/dsfield.h>
 #include <linux/if_vlan.h>
+#include <linux/mpls.h>
 #include "core.h"
 #include "rdev-ops.h"
 
@@ -710,6 +711,29 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,
 			return vlan_priority;
 	}
 
+	if (skb_headlen(skb) >= sizeof(struct ethhdr)) {
+		struct ethhdr *eh = (struct ethhdr *)skb->data;
+		struct mpls_label_stack mpls_tmp, *mpls;
+
+		switch (eh->h_proto) {
+		case htons(ETH_P_MPLS_UC):
+		case htons(ETH_P_MPLS_MC):
+			/* MPLS */
+			mpls = skb_header_pointer(skb, sizeof(*eh),
+						  sizeof(*mpls), &mpls_tmp);
+			if (!mpls)
+				break;
+
+			return (ntohl(mpls->entry) & MPLS_LS_TC_MASK)
+				>> MPLS_LS_TC_SHIFT;
+		case htons(ETH_P_80221):
+			/* 802.21 is always network control traffic */
+			return 7;
+		default:
+			break;
+		}
+	}
+
 	switch (skb->protocol) {
 	case htons(ETH_P_IP):
 		dscp = ipv4_get_dsfield(ip_hdr(skb)) & 0xfc;
-- 
1.7.10.4

Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Arend van Spriel]

On 02/17/14 17:56, Simon Wunderlich wrote:
> MPLS labels may contain traffic control information, which should be
> evaluated and used by the wireless subsystem if present.
>
> Also check for IEEE 802.21 which is always network control traffic.
>
> Signed-off-by: Simon Wunderlich<sw@simonwunderlich.de>
> Signed-off-by: Mathias Kretschmer<mathias.kretschmer@fokus.fraunhofer.de>
> ---
> Changes to first version:
>
>   * include linux/mpls.h, not the UAPI one
>   * change __constant_htons to htons
> ---
>   net/wireless/util.c |   24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index d39c371..54956eb 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -11,6 +11,7 @@
>   #include<net/ip.h>
>   #include<net/dsfield.h>
>   #include<linux/if_vlan.h>
> +#include<linux/mpls.h>
>   #include "core.h"
>   #include "rdev-ops.h"
>
> @@ -710,6 +711,29 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,

So does the name still covers what it is doing now or should we just 
callit cfg80211_classify_skb()?

>   			return vlan_priority;
>   	}
>
> +	if (skb_headlen(skb)>= sizeof(struct ethhdr)) {
> +		struct ethhdr *eh = (struct ethhdr *)skb->data;
> +		struct mpls_label_stack mpls_tmp, *mpls;
> +
> +		switch (eh->h_proto) {

It seem eh->h_proto should be the same as skb->protocol, right? So why 
not add these case statements to the switch below?

Regards,
Arend

> +		case htons(ETH_P_MPLS_UC):
> +		case htons(ETH_P_MPLS_MC):
> +			/* MPLS */
> +			mpls = skb_header_pointer(skb, sizeof(*eh),
> +						  sizeof(*mpls),&mpls_tmp);
> +			if (!mpls)
> +				break;
> +
> +			return (ntohl(mpls->entry)&  MPLS_LS_TC_MASK)
> +				>>  MPLS_LS_TC_SHIFT;
> +		case htons(ETH_P_80221):
> +			/* 802.21 is always network control traffic */
> +			return 7;
> +		default:
> +			break;
> +		}
> +	}
> +
>   	switch (skb->protocol) {
>   	case htons(ETH_P_IP):
>   		dscp = ipv4_get_dsfield(ip_hdr(skb))&  0xfc;

RE: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Kretschmer, Mathias]

> It seem eh->h_proto should be the same as skb->protocol, right? So why not
> add these case statements to the switch below?

Thought so, as well. But it seems that skb->protocol is not properly set when the packet originates from a packet socket.
And in our case we cannot set it to a fixed etherType in the bind() call since we use three different etherTypes on the same socket.

Cheers,

Mathias
 
> Regards,
> Arend
> 
> > +		case htons(ETH_P_MPLS_UC):
> > +		case htons(ETH_P_MPLS_MC):
> > +			/* MPLS */
> > +			mpls = skb_header_pointer(skb, sizeof(*eh),
> > +						  sizeof(*mpls),&mpls_tmp);
> > +			if (!mpls)
> > +				break;
> > +
> > +			return (ntohl(mpls->entry)&  MPLS_LS_TC_MASK)
> > +				>>  MPLS_LS_TC_SHIFT;
> > +		case htons(ETH_P_80221):
> > +			/* 802.21 is always network control traffic */
> > +			return 7;
> > +		default:
> > +			break;
> > +		}
> > +	}
> > +
> >   	switch (skb->protocol) {
> >   	case htons(ETH_P_IP):
> >   		dscp = ipv4_get_dsfield(ip_hdr(skb))&  0xfc;

Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[David Miller]

From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
Date: Mon, 17 Feb 2014 17:34:34 +0000

> Thought so, as well. But it seems that skb->protocol is not properly
> set when the packet originates from a packet socket.  And in our
> case we cannot set it to a fixed etherType in the bind() call since
> we use three different etherTypes on the same socket.

So many things break if the skb->protocol isn't set correctly that I
would consider such SKBs mal-formed.

You can specify the protocol number in the msghdr passed into the
send.

RE: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Kretschmer, Mathias]

> > Thought so, as well. But it seems that skb->protocol is not properly
> > set when the packet originates from a packet socket.  And in our case
> > we cannot set it to a fixed etherType in the bind() call since we use
> > three different etherTypes on the same socket.
> 
> So many things break if the skb->protocol isn't set correctly that I would
> consider such SKBs mal-formed.

Agreed.

> You can specify the protocol number in the msghdr passed into the send.

Will take a look. Thx. Need to check if there is also a way to set the protocol number when using TX_RINGs, where  we use one send() call to signal the kernel that a bunch of frames (with potentially different protocol numbers) is ready for consumption.

Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[David Miller]

From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
Date: Mon, 17 Feb 2014 19:11:05 +0000

> Will take a look. Thx. Need to check if there is also a way to set
> the protocol number when using TX_RINGs, where we use one send()
> call to signal the kernel that a bunch of frames (with potentially
> different protocol numbers) is ready for consumption.

You will have to make seperate TX_RING sends() for each cluster where
the protocol changes.

RE: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Kretschmer, Mathias]

I see. OK. If that's the proper way to do it, then so be it.  The performance hit should be negligible since to 99% it's all the same etherType.

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, February 17, 2014 20:14
> To: Kretschmer, Mathias
> Cc: arend@broadcom.com; sw@simonwunderlich.de;
> netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Subject: Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
> 
> From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
> Date: Mon, 17 Feb 2014 19:11:05 +0000
> 
> > Will take a look. Thx. Need to check if there is also a way to set the
> > protocol number when using TX_RINGs, where we use one send() call to
> > signal the kernel that a bunch of frames (with potentially different
> > protocol numbers) is ready for consumption.
> 
> You will have to make seperate TX_RING sends() for each cluster where the
> protocol changes.

Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Arend van Spriel]

On 02/17/2014 08:06 PM, David Miller wrote:
> From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
> Date: Mon, 17 Feb 2014 17:34:34 +0000
> 
>> Thought so, as well. But it seems that skb->protocol is not properly
>> set when the packet originates from a packet socket.  And in our
>> case we cannot set it to a fixed etherType in the bind() call since
>> we use three different etherTypes on the same socket.
> 
> So many things break if the skb->protocol isn't set correctly that I
> would consider such SKBs mal-formed.

That was my take as well, but how does the kernel code consider this?

> You can specify the protocol number in the msghdr passed into the
> send.
> 

Regards,
Arend

Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification

[Simon Wunderlich]

> On 02/17/14 17:56, Simon Wunderlich wrote:
> > MPLS labels may contain traffic control information, which should be
> > evaluated and used by the wireless subsystem if present.
> > 
> > Also check for IEEE 802.21 which is always network control traffic.
> > 
> > Signed-off-by: Simon Wunderlich<sw@simonwunderlich.de>
> > Signed-off-by: Mathias Kretschmer<mathias.kretschmer@fokus.fraunhofer.de>
> > ---
> > 
> > Changes to first version:
> >   * include linux/mpls.h, not the UAPI one
> >   * change __constant_htons to htons
> > 
> > ---
> > 
> >   net/wireless/util.c |   24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> > 
> > diff --git a/net/wireless/util.c b/net/wireless/util.c
> > index d39c371..54956eb 100644
> > --- a/net/wireless/util.c
> > +++ b/net/wireless/util.c
> > @@ -11,6 +11,7 @@
> > 
> >   #include<net/ip.h>
> >   #include<net/dsfield.h>
> >   #include<linux/if_vlan.h>
> > 
> > +#include<linux/mpls.h>
> > 
> >   #include "core.h"
> >   #include "rdev-ops.h"
> > 
> > @@ -710,6 +711,29 @@ unsigned int cfg80211_classify8021d(struct sk_buff
> > *skb,
> 
> So does the name still covers what it is doing now or should we just
> callit cfg80211_classify_skb()?

I'm not completely sure why this function is called 8021d anyway (isn't 802.1D 
the Spanning Tree definition?). The actual QoS definitions are appearently in 
802.1p. But I don't know both standards, so I'm just speculating. :) We can 
rename the function, but that would require more changes in drivers and 
mac80211.

Anyway, I can resend the patch along with a rename, but would prefer to get 
the first two proposed patches merged first if there are no further objections.

Cheers,
    Simon