I know it's not the typical, legal stackoverflow question, however it seems to be a very tough one as no one has a precise answer. So, back to the topic, I know there is a tunnel-id metadata matching field which was introduced in the 1.3 openflow release, if I'm not mistaken. However, are there any actions in supporting the encapsulation and decapsulation process of a tunnel protocol, like GTP? I suppose there are, as the tunnel metadata is present in the openflow matching implementation, so in this case what are the specific encap/decap actions, in order to apply therefore routing decisions on the actual tunneled ip packet?
Asked
Active
Viewed 966 times
1 Answers
1
The tunnel_id is a generic field to which the identifiers of tunnelling protocols should be matched (cf. OpenFlow spec 1.5):
The mapping of the optional encapsulation metadata in the Tunnel ID field is defined by the logical port implementation, it is dependant on the type of logical port and it is implementation specific. We recommend that for a packet received via a GRE tunnel including a (32-bit) key, the key is stored in the lower 32-bits and the high bits are zeroed. We recommend that for a MPLS logical port, the lower 20 bits represent the MPLS Label. We recommend that for a VxLAN logical port, the lower 24 bits represent the VNI.
So basically, yes, if some device would parse GTP headers, it should (could) map the TEID to the tunnel_id field and all of this seems to be done directly within the data path - automatically and - according to the spec - without any further actions that can/have to be applied.
Regarding GTP: I am not aware in any generally available OpenFlow hardware that supports it (I'd love to, we have use-cases for that..).
StephenKing
- 36,187
- 11
- 83
- 112
-
I informed myself a lot better about the GTP thing, and the short answer is NO, by the current OpenFlow implementation the TEID in the gtp header won't be recognized as GTP itself is not switch-defined. – pa5h1nh0 Jun 22 '16 at 16:29